Files
Uploading and downloading binary content (for FILE-typed fields) goes through short-lived signed URIs rather than streaming through the API directly.
Request an upload URI
GET /data/{tenant}/upload
Returns a signed URI the client uploads the file bytes to.
Interview needed. Document the full upload flow: what the returned URI points at, how the resulting file is then referenced when creating/patching an object (the token/id linking upload → FILE field), expiry, and size/type limits.
Request a download URI
GET /data/{tenant}/download/{id}
Returns a signed URI to download the binary identified by id.
Interview needed. Document what id refers to (file id vs. object id), URI expiry, and how it relates to the binaries/assets endpoints.
Inline preview vs. download
The returned signed URI resolves with a Content-Disposition that depends on the binary's content type:
| Content type | Content-Disposition | Behaviour |
|---|---|---|
application/pdf | inline | Browsers render the file in place instead of downloading it — the URI can be used directly as an <iframe> source. |
image/* | inline | The URI can be used directly as an <img> source. |
| Everything else | attachment | Browsers prompt a download. |
For inline content types, the response also omits the X-Frame-Options: DENY header that is otherwise set, since inline previews are commonly embedded in a frame within the current page. This is automatic and content-type-driven — there is no separate parameter or endpoint to request one disposition over the other.
The signed URI is time-limited. A preview kept open longer than the URI's expiry (for example, an overlay left open) needs to request a fresh download URI rather than reusing the original one.