Mint an asset over existing bytes (dedup fast-path)
Zero-byte fast-path: mints a new asset UUID over a blob the platform already has, identified by its blake3 hash.
Trust boundary: resolves only against blobs the platform itself
ingested and hashed, and only those the calling account is authorized
to use — the client hash is a lookup key, never an authority to
register new content. A miss and “exists but not yours” are
deliberately indistinguishable (404 blob_not_found).
Authorizations
Authorization: Bearer <credential>. The credential is one of: an account-scoped API key (comfyui-…), accepted on Cloud and serverless; a Comfy Cloud session JWT; or an OAuth access token issued for the Comfy Cloud resource. Which kinds a given deployment accepts is deployment configuration — an API key always works on Cloud and serverless, and a deployment that does not accept JWT bearers answers 401 with a message saying so. Self-hosted accepts unauthenticated requests by default and can be configured with a static bearer token.
Body
"blake3:9f8a1c0d..."
"photo.png"
Optional retention override in seconds (60s–7d): the asset's expires_at becomes now + expires_in, replacing the platform's default retention. Implementations without configurable retention ignore it. The bounds apply to this override only — the platform default is operator-configured and may lie outside them.
60 <= x <= 60480086400
Response
An identical reference already existed; returned as-is.
A user-owned record identified by a server-assigned UUID, backing an immutable blob whose content carries a server-computed blake3 hash. hash may be computed lazily: an asset record (and its retrievable bytes) can exist before its hash is filled in. On an output, job_metadata carries the labels its producing job was submitted with, so code holding only the asset knows which run it came from. It is absent for assets no job produced, for outputs of a job sent without labels, where the serving surface keeps no job labels, and when the labels could not be read: so job_id without job_metadata does not prove the job had no labels. A create whose file path and bytes match an existing output answers with that output, so its job_id and job_metadata are the output's.
"9f8a1c0d-2b3e-4f56-8a7b-1c2d3e4f5a6b"
blake3:<hex>; null while lazily computed.
"blake3:9f8a1c0d..."
4816293
"image/png"
Short-lived content URL (signed, or proxy-served).
"photo.png"
On create responses: distinguishes a brand-new blob (true) from a dedup hit against bytes the platform already had (false).
Retention deadline for the asset itself (distinct from url_expires_at, the signed URL's validity). Null or absent means the asset is non-expiring. On a dedup-hit create response the deadline may be later than now + the requested/default retention: re-referencing content extends its retention, never shortens it.
ID of the job that produced this asset. Absent for assets no job produced, such as a fresh upload.
The labels the producing job was submitted with, read through job_id on each read. Absent for assets no job produced, for outputs of a job sent without labels, where the serving surface keeps no job labels, when the job is gone, and when the labels could not be read: so job_id without job_metadata does not prove the job had no labels.