Initiate multipart uploads for a set of files
Initiate a multipart upload for several large files in one request, so a bulk transfer costs one round trip and one unit of rate limit instead of one per file.
More details
More details
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
API key for authentication
Headers
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
Files to initiate, at most 25 per request. Each item is validated on its own: a bad descriptor is rejected without affecting its siblings.
1 - 25 elementsValues 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.