POST
Re-sign part URLs for an upload already in flight
Request · Guide: Upload files
This is what makes a long bulk transfer work. Part URLs are deliberately short-lived, so a 30-file transfer will outlive the URLs it started with; ask for the parts still outstanding and carry on.Nothing about the upload changes. Parts already uploaded under earlier URLs stay uploaded, the upload id is unchanged, and completion still expects the full part list.The input should contain:
  • id: the ID from the multipart upload initiation
  • key: the S3 key from the multipart upload initiation
  • partNumbers: the parts to re-sign, 1-based and within the upload’s totalParts
An id/key pair that does not belong to your API key’s account returns 404, the same as one that never existed.

Authorizations

x-api-key
string
header
required

API key for authentication

Headers

Idempotency-Key
string

Accepted for client uniformity but IGNORED on this endpoint. It has no side effects, and it exists to hand back part URLs newer than the ones you hold — they last 900 seconds, so replaying a cached response inside the 24h window would return the very URLs that just expired. Every request executes fresh: no 24h window, no replay, no Idempotent-Replayed header, and no key-reuse 422.

Body

application/json
id
string
required

ID from the multipart upload initiation

Example:

"upload_abc123xyz"

key
string
required

S3 key from the multipart upload initiation

Example:

"org_123/workspace_456/device/file_abc/document.pdf"

partNumbers
number[]
required

Part numbers to re-sign. 1-based, and each must be within the upload's totalParts.

Required array length: 1 - 2500 elements
Example:

Response

Freshly signed URLs for exactly the requested parts