Integrate record activity and attachments
Use authorized parent paths, bounded activity pages, idempotent posts, and scan-aware downloads.
Demo baseline · November 13, 2026Select the parent path
Agent endpoints are rooted at /api/records/{entity}/{id} and portal endpoints at /api/portal/records/{entity}/{id}. Open the parent with the intended role before testing. Use GET /overview for current posting/upload permissions and initial results, and GET /configuration for the active file policy.
| Operation suffix | Expected behavior |
|---|---|
| GET /activity | Bounded activity. Use the returned cursor to continue older pages with the same filters. |
| POST /activity | Send a permitted work_note or comment, body and UUID requestKey. Verify the audience and retain the same key only for an exact retry. |
| GET /attachments | Read the authorized file list, current scan state and pagination. |
| POST /attachments | Send raw application/octet-stream bytes with filename and visibility parameters and a UUID Idempotency-Key. Check the resulting attachment ID and scan state. |
| GET /attachments/{attachmentId}/content | Retrieve only when the parent, audience and clean-file checks permit it. |
Handle processing and retries
Uploads can progress through uploading, quarantined and scanning before a clean or blocked outcome. An interrupted upload may have durable metadata even when the client times out. Use the original key and payload for an exact supported retry, then confirm that a single attachment exists. If a file remains pending, check the scanner and storage evidence in Activity & attachment governance. For a missing comment, compare audience and parent access before retrying.