Skip to main content

Files API

Generic file storage for everything that needs an attachment — MMS images, WhatsApp media, agent-side documents, message templates, campaign assets. Files live in Cloud Storage; URLs are signed and time-limited. Base path: /api/v1/files Authentication: API key (X-API-Key) or session JWT. Upload limits: 25 MB per file (multipart form data).

Example — upload an image for an MMS

The upload response carries the file ID and a signed URL:
Pass the file ID to POST /api/v1/messages/sms (or serve the signed URL as the attachment) to send an MMS — the end-to-end send is in Attach the file to an MMS below.

Browse and clean up files

List, fetch, and delete round out the round trip — the Node SDK wraps all three as typed methods:
Over REST the same three calls are GET /api/v1/files/, GET /api/v1/files/{id}, and DELETE /api/v1/files/{id} — the endpoint table above carries the full shapes.

Presigned download URLs

The signed URL returned on upload (and from GET /api/v1/files/{id}) is short-lived. When you need a fresh download link — or one with a different lifetime — call GET /api/v1/files/{id}/presign to mint a new S3-style presigned read URL for an existing object. Use the optional ttl_ms query parameter to control how long the URL stays valid:
The response:
A request for a file ID that does not exist in your tenant namespace responds 404; a ttl_ms outside the 1-minute-to-7-day band is clamped, not rejected.

Attach the file to an MMS

Uploading only stores the asset — sending it as an MMS is a second call that passes the returned signed URL as media_url:
Passing media_url turns the SMS into an MMS with the attachment inline — the send is rejected before dispatch if the URL fails the HTTPS fetch or the media-type check, so the upload’s signed read URL (which resolves over Google’s storage domain) is the reliable shape. Full MMS semantics (multi-attachment media_urls, the NANP coverage gate, media policy) live on the MMS channel page.

See also