# Initiate multipart uploads for a set of files
Source: https://docs.file.ai/api-reference/uploads/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.

post /prod/v1/files/upload/multipart/batch

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.

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`.