Files API

The Files API lets a workspace token list, upload, and download the same ordinary Files records the app uses. There is no second machine ingest service. Uploads use the existing presign, storage, finalize, and malware-scan path.

Scopes

files.records.read       list and inspect file metadata
files.records.write      update reversible metadata
files.records.propose    propose an archive for owner approval
files.content.write      initialize and finalize a scanned upload
files.content.read       read active file bytes through a short-lived URL

Upload bytes through the scan gate

POST /v1/tools/files_content_upload_init
PUT  <the returned short-lived storage URL>
POST /v1/tools/files_content_upload_finalize

The PUT uses the exact headers returned by init and carries no workspace token. Finalize verifies the stored object, then parks the row at scan_pending. Only an explicit clean GuardDuty verdict changes it to active. Threat, unsupported, failed, and unknown verdicts remain unavailable.

Machine ingest fails closed unless the workspace has an explicit byte allowance. Amolfi does not infer a storage limit from the plan while those commercial caps are still being ratified.

Contracts and the security boundary

Ordinary Files includes user-uploaded contracts. The category label is editable, so using contracts as an access-control boundary would not protect anything. Separately managed signed-provider documents remain excluded because they live behind signing-specific tables and actions.

Use the CLI

amolfi files list
amolfi files put ./pricing-model.md
amolfi files get <file_id> --output ./pricing-model-copy.md

files put waits for the scanner. A clean file becomes available. A held file exits nonzero and its content is never served. Subscribe to file.available and file.held if your system should be told instead of polling.

AuthenticationWebhooksThe CLI