Create an upload
The two-step path for a large payload: ask for a signed URL, PUT the bytes, then reference the upload by ID.
upload_id to whatever needs the data.
filename, contentType, and sizeBytes are all required. sizeBytes is a string, because it is a 64-bit integer.
The three steps
1. Create the upload. The response carriesinfo.uploadUrl, a short-lived signed URL, and info.uploadUrlExpiresAt. The status is UPLOAD_STATUS_PENDING: the row exists, the bytes do not.
2. PUT the bytes to that URL. Upload straight to storage, not through the Cadenya API. Match the Content-Type you declared.
UPLOAD_STATUS_COMPLETE.
3. Reference the upload_id. Hand the ID to the resource that needs the payload, such as a memory entry too large to inline:
You cannot reference an upload before its bytes land
This is the guard to code around. Referencing an upload still inUPLOAD_STATUS_PENDING is a 400, with the reason spelled out:
GET /uploads/{id} for UPLOAD_STATUS_COMPLETE before you use the ID if your upload and reference are decoupled.
The status lifecycle
EXPIRED upload cannot be revived. Create a new one and PUT again. uploadUrlExpiresAt on the create response tells you how long you have.
Related
Get an upload
UPLOAD_STATUS_COMPLETE before referencing.Create a memory entry
uploadId for an entry too big to inline.Set tool call content
Create an objective
Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Path Parameters
Workspace ID.
"workspace_01HXKD2E5NQM3T9AYWCF133E3Q"
Body
Response
OK
A handle representing a single file upload flow. Clients call CreateUpload to receive a short-lived presigned URL, PUT the file directly to object storage, then reference the upload by id when creating or updating resources that accept binary content.
Uploads are one-shot: once consumed by a creating or updating resource the upload transitions to UPLOAD_STATUS_CONSUMED and cannot be reused. Unused uploads expire and are garbage-collected.