Skip to content

support_attachment_finalize

Confirm that an upload landed.

Tool

support_attachment_finalize

Confirm that an upload landed.

Confirm that an upload landed. Storage is asked whether the object exists and how large it is; if it is not there the call is refused and the attachment stays pending. Its first 4 KiB are then read and checked against the content type the attachment was created with: if the bytes are something else — an svg uploaded as a png, html uploaded as text — the object is DELETED, the attachment becomes rejected, and the call answers 400 with a message beginning "attachment_rejected" and naming the reason. That state is terminal: calling finalize again returns the same 400, and the file must be created and uploaded afresh. On success the attachment becomes uploaded — it can now be named in support_message_create and carries a download URL served under the verified type. Calling it again on an uploaded attachment is safe and simply returns a fresh download URL

Behavior

HTTP
POST /support/attachments/finalize

Arguments

Name
Type
Required
Description
attachmentId
string
•
The attachment whose upload should be confirmed, as returned by the create call

Response

Field
Type
Always
Description
id
string
•
Attachment id
status
string
•
pending: the row exists and an upload URL was issued, but no bytes have been confirmed. uploaded: finalize saw the object in storage and its first bytes matched the declared type. rejected: they did not, the object was deleted, and this attachment is finished — the state is terminal. Only uploaded attachments can be attached to a message or downloaded
fileName
string
•
Display name of the file
threadId
string
•
Thread this attachment belongs to
createdAt
string
•
ISO-8601 creation timestamp
messageId
string
•
The message that carries this attachment, or null while nothing claims it yet
sizeBytes
integer
•
Size in bytes: what the caller declared while the attachment is pending, what storage reported once it is uploaded
uploadedAt
string
•
ISO-8601 timestamp of the confirmed upload, or null while pending
contentType
string
•
MIME type declared when the attachment was created
downloadUrl
string
•
Short-lived signed URL to read the uploaded file
rejectedReason
string
•
Why finalize refused the file — signature_mismatch, not_utf8, nul_byte or markup_in_text — or null in any state but rejected

Try it

Confirm that an upload landed.

When to use

Confirm that an upload landed. Storage is asked whether the object exists and how large it is; if it is not there the call is refused and the attachment stays pending. Its first 4 KiB are then read and checked against the content type the attachment was created with: if the bytes are something else — an svg uploaded as a png, html uploaded as text — the object is DELETED, the attachment becomes rejected, and the call answers 400 with a message beginning "attachment_rejected" and naming the reason. That state is terminal: calling finalize again returns the same 400, and the file must be created and uploaded afresh. On success the attachment becomes uploaded — it can now be named in support_message_create and carries a download URL served under the verified type. Calling it again on an uploaded attachment is safe and simply returns a fresh download URL

Example

Ask your agent something like this:

Confirm that an upload landed.

The agent will invoke support_attachment_finalize with these arguments:

{
  "attachmentId": "<attachmentId>"
}

Esc

Start typing to search the docs.

↑↓navigate↵select