POST
Initiate multipart uploads for a set of files
Request · Guide: Upload files
Accepts up to 25 files in files, and at most 2500 presigned part URLs across the whole batch — a batch over that combined cap is rejected with BATCH_PARTS_TOO_LARGE, and nothing is created. Split the batch, or raise partSizeLimit so the same bytes need fewer parts.Part sizing is unchanged: for a given fileSize and partSizeLimit, a file in a batch gets exactly the partSize and totalParts the single-file endpoint would return for it.defaults supplies values for files that omit them; a per-file value always wins, including an explicit false. Every field a file may carry is the one the single-file endpoint accepts.Files are accepted or rejected independently: a descriptor that fails validation is returned as rejected with its own error, and its siblings are still initiated. Check accepted / rejected and the per-file status — a response where every file is rejected is still a 201.Each part URL is valid for 900 seconds. For a transfer that runs past that, re-sign just the parts still outstanding with POST /v1/files/upload/multipart/urls/refresh; parts already uploaded stay uploaded.Then finalize with POST /v1/files/upload/multipart/complete/batch.This response is the only copy of the upload handles it creates, and it is too large to cache, so Idempotency-Key is accepted but ignored here — a retry initiates a fresh set of uploads rather than replaying the first. Abandoned uploads expire under the bucket lifecycle policy. The complete endpoint IS idempotent.Note the field names, which differ from the single-file response: here uploadId is the S3 multipart upload id — the value to send as id when completing or refreshing — and fileId is the internal file id. The single-file endpoint calls them id and uploadId.

Authorizations

x-api-key
string
header
required

API key for authentication

Headers

Idempotency-Key
string

Accepted for client uniformity but IGNORED on this endpoint. Its response is the only copy of the upload handles it creates and is far larger than the idempotency cache can hold, so a replay would return a placeholder carrying none of them. The key is accepted and ignored rather than trading a duplicate set of uploads — which the lifecycle policy sweeps — for handles that cannot be recovered. Every request executes fresh: no 24h window, no replay, no Idempotent-Replayed header, and no key-reuse 422.

Body

application/json
files
object[]
required

Files to initiate, at most 25 per request. Each item is validated on its own: a bad descriptor is rejected without affecting its siblings.

Required array length: 1 - 25 elements
defaults
object

Values applied to every file that does not set them itself. A per-file value always wins.

Response

The batch was processed. Inspect results for each file's outcome — a batch where every file was rejected is still a 201.