Response deviation details for the Upload API flow

Summary

As part of upcoming Upload API optimizations, some values in upload responses will change. The upload flow itself remains fully supported and requires no changes to how you call it. Most of the affected values are internal references that were never intended for direct use. 

This notice lists each response deviation, with the current state shown against the future state, so you can confirm none of your integrations depend on the values that are changing. 

Here are all the key changes at a glance:

Change details 

Step 1 - Get closest Amazon S3 upload endpoint

Change to the upload target in the upload response The upload response now returns a different upload target host. You may notice this in logs, response inspection, or custom tooling. The upload flow itself remains fully supported. 

The updated flow returns a Bynder hosted gateway URL, whereas the current flow returns a raw AWS S3 bucket URL. The future state host follows the pattern https:///api/1/boss/v4upload/. 

Current State

Future State

Step 2 – Initialise upload

Value structure change for multipart_params.key and s3_filename

In the current state, multipart_params.key and s3_filename hold the same value in the initialise response. The key names stay the same, but the structure of their values will differ going forward.

Current State

Future State

Amazon-derived values in the initialise upload response 

In the current state, these values come from AWS and are valid. In the future state, they are abstractions that are no longer usable for any purpose. In general, these values were never intended to be used. 

The fields below are part of the same multipart_params object shown in the previous change. They are shown here on their own to make the difference clear.

Current State

Future State

Link to API documentation: Initialise upload

Step 3A - Upload file in chunks 

Value changes in the chunk upload response 

The chunk upload XML now returns Bynder-based values, such as the bucket and key, instead of S3 values. These values do not represent the location of the object in Bynder storage and should not be used to construct a URL. They will differ from this point onward, and we do not expect them to be used. 

The ETag stays identical between the current and future states. 

Current State

Future State

Link to API documentation: Upload file in chunks

Step 6 - Save as a new asset 

Default values in the save response originalFileS3location 

In the current state, the values in originalFileS3location could be used to locate the file. In the future state, this information is still returned so that existing integrations do not break, but using these values to construct a URL will not work. The response now returns default umbrella values rather than the exact values specific to the object.

Current State

Future State

Link to API documentation: Save as a new asset

General performance 

Chunk upload requests may experience higher latency in the update flow compared to the current performance. Uploads still complete successfully.

Updated August 06, 2026 11:25