Initialize a block based file replacement job
Changed onInitializes a block based replacement job for an existing file. The init response provides a set of pre-signed URLs for uploading individual blocks, transferred over separate requests. Once the replacement file content is uploaded, the finalize endpoint is called to finalize the replacement.
The file's assetId, permissions, and metadata are preserved while the content is replaced.
NOTE: For files 10 MB or larger, direct replacement is not supported. Clients must use this block-based replacement workflow. block-based transfer is allowed for any size
Replacement Flow Overview
1. Initiate Replacement:
Client sends a POST request to initiate the block replacement and receives a response with URLs for uploading individual blocks and finalizing the transfer.
2. Upload Blocks:
Client issues PUT requests to the provided Block Transfer URLs, sending file data in chunks. These can be uploaded in parallel.
NOTE: ####Uploading File Blocks After receiving transferLinks, clients can use them to upload individual blocks: PUT <transferURL> <binary data>
- Authorization Header: Must NOT be included in the request.
- Success Response: 200 OK indicates successful block upload.
- Expiration Handling: Each upload session is time-bound. If blocks are not uploaded within the specified expiration window (urlExpirationDate field from the initiation response), the operation may fail.
- Always check and respect the urlExpirationDate timestamp in the response from the Block Upload Init endpoint.
3. Finalize Replacement:
After all blocks are uploaded, the client calls the Block Finalize URL to trigger the replacement.
4. Monitor:
Finalize operation's response includes a Monitor URL to check the final status.
Initialize the Block-Based Replacement
This endpoint allows clients to initiate the replacement of an existing file's content using block-based transfer.
NOTE:
- The expiration duration of transfer URLs is explicitly provided to the client in the response
- The Content-Type must match the existing file's media type. Attempting to change the content type will result in a 415 Unsupported Media Type error.
Request
- Base URL: https://cloudstorage.adobe.io/v1
- URL: https://cloudstorage.adobe.io/v1/files/{assetId}/upload/init
- Auth: HTTP bearer
Path parameters
A globally unique identifier for the asset
The ID of the asset to get.
Headers
The X-Request-Id header is used to identify a request.
It can be used to correlate logs and other resources and is intended to be a non-persistent identifier.
Request body
Example request
{
"size": 1048576,
"mediaType": "image/jpeg",
"blockSize": 1048576,
"options": {
"autorename": true
}
}Response
Success - Upload Id along with urls for upload
Example response
{
"uploadId": "123e4567-e89b-12d3-a456-426614174000",
"blockSize": 1048576,
"urlExpirationDate": "2021-01-01T00:00:00Z",
"transferLinks": [
{
"partNumber": 1
}
]
}Changes
- warning
added the new
conflictenum value to theresponse property for the response status - warning
added the new
conflictenum value to theresponse property for the response status - warning
added the new
conflictenum value to theresponse property for the response status - warning
added the new
conflictenum value to theresponse property for the response status - warning
added the new
conflictenum value to theresponse property for the response status - warning
added the new
conflictenum value to theresponse property for the response status - warning
added the new
conflictenum value to theresponse property for the response status - warning
added the new
conflictenum value to theresponse property for the response status - warning
added the new
conflictenum value to theresponse property for the response status
- warning
- info
endpoint added
- info