Skip to main content
POST

Overview

Begin a direct-to-cloud upload of a file. The server records the file metadata, splits the upload into parts, and returns presigned URLs that the client uploads each part to.
Direct-to-cloud file uploads support files up to 250 GB. However, Lenses and the Lens API do not support files larger than 512 MB.
The full direct-to-cloud upload flow is:
  1. Initiate the upload (this endpoint) — receive upload_id and presigned parts.
  2. PUT each part’s bytes directly to its presigned url. Capture the ETag response header from each PUT — that is the part’s part_token.
  3. Optionally, checkpoint completed parts so they can be skipped on resume.
  4. Optionally, generate fresh URLs for parts whose presigned URLs are about to expire.
  5. Complete the upload, supplying a part_token for each non-checkpointed part.
If something goes wrong, abort the upload to release server-side resources.
Part numbers are 1-based. The first part returned by this endpoint has part_number: 1, not 0. Using part_number: 0 in any subsequent call (/parts/urls, /parts/checkpoint, /complete) is rejected with 400 invalid_upload_parts.

Request Body

string
required
Name of the file being uploaded
string
required
MIME type of the file (e.g. image/png, text/csv)
integer
required
Total size of the file in bytes
boolean
When true, if a matching in-progress upload for this filename already exists for the organization, the server reuses it and returns only the parts that have not been checkpointed.“Matching” requires the existing record’s file_type and num_bytes to equal the request’s; a mismatch fails with 409. If no in-progress upload exists, behavior is identical to resume_if_started=false.

Response

string
Server-generated identifier for the upload. Use it in subsequent calls to checkpoint, generate URLs, complete, or abort.
string
Internal unique identifier that will be assigned to the completed file
string
Name of the file being uploaded
integer
Total size of the file in bytes
integer
Number of parts the file has been split into
integer
Size in bytes used to split the file into parts. May be omitted for some upload backends.
string
Whole-file checksum algorithm supported by the storage backend. One of crc32c or none. If crc32c, the client may compute a CRC32C over the full file and pass it as integrity_checksum on Complete Upload for server-side verification. If none, the backend does not support checksum verification — clients should not send one.
boolean
true when the response reuses an existing in-progress upload (because the request specified resume_if_started=true and a matching record was found). false for a freshly created upload. When true, parts contains only the not-yet-checkpointed subset.
array
Presigned descriptors for each part of the upload