--- title: "Download the content of one TEA Artifact revision" method: GET path: "/artifact/{uuid}/{artifactVersion}/download" tags: ["TEA Artifact"] --- # Download the content of one TEA Artifact revision `GET /artifact/{uuid}/{artifactVersion}/download` Download the content of a specific revision of a specific TEA Artifact. This endpoint returns the bytes of one `format` of the artifact revision. It is how a TEA server hosts artifact content itself: a format that has no external `url` is retrieved from here, selected by its `mediaType`. A format that has a `url` is retrieved from that external location instead, and this endpoint is not required to serve it. A TEA access token is sent only to the TEA server's own API base URL. External `url` targets are retrieved without it. They are openly accessible or require credentials the client arranges separately. Expiring storage links should not be published in `url`; the server answers from this endpoint, including with `302`. When serving the content itself (`200`), servers shall return a strong `ETag` for the HTTP representation selected after negotiation, including content coding, and shall honor `If-None-Match` with `304`. `ETag` is the only conditional validator for these downloads. Servers that support `HEAD` for this operation shall return the same headers as `GET` without a response body. `302` redirects are outside conditional semantics: `If-None-Match` applies only to the TEA-hosted download response, not to following an external `Location`. How long a cache may retain the response depends on whether the content is publicly accessible: see `artifact-cache-control-immutable`. Immutability does not imply that shared caches may store access-controlled responses. Successful responses include `Content-Location` as an absolute URL of this versioned download including the `mediaType` query parameter. That URL identifies the revision and format; HTTP content coding can still be negotiated. ## Path parameters - `uuid` string, uuid, required — A UUID in lower case (RFC 9562) - `artifactVersion` integer, required ## Query parameters - `mediaType` string ## Headers - `If-None-Match` string ## Response `200` The content of the requested TEA Artifact format. The wire `Content-Type` is the `mediaType` of the format returned. The response content key is `*/*` because that type varies by format. `Content-Encoding`, when present, names the HTTP content coding of the selected representation. `Content-Location` identifies the revision and format; HTTP content coding can still be negotiated. `Vary` follows `artifact-vary`. ## Other responses - `302` — The selected representation is available at another location, for example object storage addressed by a pre-signed URL. The client follows the `Location` header. Changing only this response's `Location`, while preserving the artifact or signature bytes for the selected UUID, version, and format after HTTP content coding is removed, does not require a new artifact or collection version. Publishing a different external `url` or `signatureUrl` on the artifact metadata is a separate change and shall follow the `artifact-format` rules for those fields. A client shall not send its TEA access token when following a redirect to a different origin. - `304` — The representation selected after negotiation has not changed (RFC 9110). The response body is empty. Servers shall repeat `ETag` and `Content-Location` from the would-be successful response for that representation, and shall repeat `Cache-Control` and `Vary` when the corresponding `200` carries them. - `400` — Request was invalid. For paginated requests, this includes malformed, invalid, expired, or conflicting `pageToken` values, including conflicts with continuation parameters or path parameters (`error: INVALID_PAGE_TOKEN` when a TEA error body is present). Other malformed requests may use `error: INVALID_REQUEST`. - `401` — Authentication required, or the presented access token is expired, revoked, or otherwise invalid. Servers shall include a `WWW-Authenticate` header as defined in RFC 6750 section 3. On the `invalid_token` error a client may obtain a fresh token from `/token` and retry the request once (RFC 6750 section 3.1). The `WWW-Authenticate` challenge remains the primary signal; an `error-response` body is optional. Servers that require no authentication on any endpoint shall not return this status. On a TEA server where some data is available without authentication, but not all, protected endpoints return `401` when no valid token is presented; endpoints that do not require authentication answer without requiring a Bearer token. A protected object shall not answer `404` solely because the client is unauthenticated: absence of a valid token yields `401`, so the client flow can discover that authentication is required. - `403` — The client is authenticated, but is not authorized to access this resource or perform this operation. Authorization decisions are server-specific and are not constrained by this specification. Servers may instead conceal the existence of a resource from an authenticated but unauthorized client by answering `404` (see `404-object-by-id-not-found`). Clients shall treat `403` and that concealing `404` as non-access; neither implies that retrying with the same token will succeed. - `404` — Either the object is unknown to this server, or — where an endpoint documents it — the server does not provide an optional capability or sub-resource for that object. The cases are told apart by the TEA error body, never by the status alone: - `error: OBJECT_UNKNOWN` — no such object (or its existence is concealed from this client). - `error: NOT_IMPLEMENTED` — optional capability or endpoint not provided (for CLE: lifecycle data; for `/token`: the token endpoint is not implemented). CLE is optional in TEA; clients shall not treat this as a failure of the object itself where the capability is optional. - `error: SIGNATURE_NOT_FOUND` — the artifact revision and format exist, but no signature is published for that format. This reveals that the artifact exists; a server concealing an artifact shall answer `OBJECT_UNKNOWN` for every sub-resource of it, signatures included. Concealment applies only after authentication. A request to a protected object with no valid access token shall receive `401` (see `401-unauthorized`), not a concealing `404`. Clients shall not infer from `404` alone whether the object is absent, withheld, or lacking an optional capability or sub-resource. - `406` — The artifact revision exists, but has no format matching the requested `mediaType` or `Accept` header. Body is a TEA `error-response` with `error: NO_ACCEPTABLE_FORMAT`. `NO_ACCEPTABLE_FORMAT` reveals that the artifact revision exists. A server concealing an artifact from a client shall answer `404` with `error: OBJECT_UNKNOWN` for every sub-resource of it, formats included, instead of this status. ## Changes - **2026-09-23** `4f09e14d1ee0` — 1 warning - the optional response header `Content-Encoding` removed for the status `200` - **2026-09-23** `03c7ffdc11d0` — 1 warning - the optional response header `Content-Encoding` removed for the status `200` - **2026-09-20** `f698addb5d2b` — 10 info - added the optional property `message` to the response with the `400` status - added the optional property `message` to the response with the `401` status - added the optional property `message` to the response with the `403` status - added the optional property `message` to the response with the `404` status - …6 more - **2026-09-20** `56e8a7148549` — 1 breaking, 3 info - removed the media type `application/octet-stream` for the response with the status `200` - added the new optional `header` request parameter `If-None-Match` - added the media type `*/*` for the response with the status `200` - added the non-success response with the status `304` - **2026-09-20** `76f1dba21cda` — 1 breaking, 3 warning, 2 info - removed the media type `*/*` for the response with the status `200` - the optional response header `Content-Location` removed for the status `200` - the optional response header `Vary` removed for the status `200` - deleted the `header` request parameter `If-None-Match` - …2 more [Full history](https://skmtc.dev/cyclonedx/apis/transparency-exchange-api/changes/artifact/:uuid/:artifactVersion/download/get.md) --- [API](https://skmtc.dev/cyclonedx/apis/transparency-exchange-api.md) · [All operations](https://skmtc.dev/cyclonedx/apis/transparency-exchange-api/llms.txt) · [OpenAPI document](https://skmtc.dev/cyclonedx/apis/transparency-exchange-api/revisions/4d4c7959bc18?raw)