---
title: "Get the latest collection of a TEA Product Release"
method: GET
path: "/productRelease/{uuid}/collection/latest"
tags: ["TEA Collection"]
---

# Get the latest collection of a TEA Product Release

`GET /productRelease/{uuid}/collection/latest`

## Request

- Base URL: `http://localhost/tea/v1.0.0`
- URL: `http://localhost/tea/v1.0.0/productRelease/{uuid}/collection/latest`
- Auth: one of:
  - HTTP bearer
  - none

Get the latest TEA Collection belonging to the TEA Product Release, that is,
the collection with the greatest published `version`.

`404` means the release is unknown; a release always has a latest collection.

## Path parameters

- `uuid` string, uuid, required: A UUID in lower case (RFC 9562)

## Response `200`

Requested TEA Collection found and returned

- Collection: A collection of security-related documents. Every component release and product release has a collection. If no artifacts have been published when the release first becomes retrievable, the server serves version 1 with an empty `artifacts` list and `updateReason.type: INITIAL_RELEASE`. That version is immutable like any other; the first artifacts are published as version 2.
  - `uuid` string, uuid, required: A UUID in lower case (RFC 9562)
  - `version` integer, required: TEA Collection version, incremented by 1 each time its content changes. Versions start with 1. Content changes include replacing an embedded artifact with a newer revision (for example one published because an external `url` or `signatureUrl` changed). If a Collection adopts that new artifact revision, the server shall publish a new Collection version. Previously published Collection versions shall remain unchanged. Classification of that adoption follows `collection-update-reason-type`.
  - `createdDate` string, date-time, required: Timestamp, RFC 3339 in UTC with the `Z` designator. Offsets are not accepted; servers shall convert to UTC before emitting. Fractional seconds are optional and preserved as sent. All timestamps in this specification use this schema.
  - `belongsTo` 'COMPONENT_RELEASE' | 'PRODUCT_RELEASE', required: Indicates whether a collection belongs to a component release or a product release
  - `updateReason` CollectionUpdateReason, required: Reason for the update to the TEA collection
    - `type` 'INITIAL_RELEASE' | 'VEX_UPDATED' | 'ARTIFACT_UPDATED' | 'ARTIFACT_ADDED' | 'ARTIFACT_REMOVED', required: Type of TEA collection update. `VEX_UPDATED` covers adding or revising an artifact of type `VULNERABILITIES`, including a revision whose external `url` or `signatureUrl` changed. VEX and VDR share that type. `ARTIFACT_UPDATED` covers a new revision of an artifact whose type is not `VULNERABILITIES`, including a revision whose external `url` or `signatureUrl` changed. Replacing an embedded artifact revision solely because its published `url` or `signatureUrl` changed is `VEX_UPDATED` when the artifact type is `VULNERABILITIES`, and `ARTIFACT_UPDATED` otherwise. Removing an artifact, including one of type `VULNERABILITIES`, counts as `ARTIFACT_REMOVED`. The first Collection version shall use `INITIAL_RELEASE`. In subsequent versions, adding or revising an artifact of type `VULNERABILITIES` counts as `VEX_UPDATED`. When multiple change kinds occur, the server shall select `updateReason.type` using the precedence rule below. When a collection version other than the first contains changes of more than one kind, the server shall set `updateReason.type` to the first applicable value in this order: `VEX_UPDATED`, `ARTIFACT_REMOVED`, `ARTIFACT_ADDED`, `ARTIFACT_UPDATED`. `comment` can describe the other changes. A client that needs the complete set of changes should compare the version with the previous one.
    - `comment` string: Free text description
  - `artifacts` Artifact[], required: Array of TEA Artifact objects (may be empty).
    - `uuid` string, uuid, required: A UUID in lower case (RFC 9562)
    - `version` integer, required: Revision number, starting at 1 and incremented by 1 for each new revision of the same artifact UUID. Together with `uuid` uniquely identifies the TEA Artifact. Successive revisions cover content changes and changes to any published field, including external `url` or `signatureUrl` values. Each published revision is immutable. For a fixed artifact UUID, version, and format, the server shall ensure that successful content retrieval through its download endpoint, including retrieval after following redirects, yields unchanged artifact bytes after HTTP transfer coding and content coding are removed, and that successful signature retrieval through its signature download endpoint yields unchanged signature bytes on the same terms. Changing only a download response's `Location`, or only its HTTP content coding, while preserving those bytes, does not require a new artifact or collection version.
    - `name` string: A human-readable name for the artefact
    - `type` 'ATTESTATION' | 'BOM' | 'BUILD_META' | 'CERTIFICATION' | 'FORMULATION' | 'LICENSE' | 'RELEASE_NOTES' | 'SECURITY_TXT' | 'THREAT_MODEL' | 'VULNERABILITIES' | 'OTHER', required: Type of TEA Artifact.
    - `createdDate` string, date-time, required: Timestamp, RFC 3339 in UTC with the `Z` designator. Offsets are not accepted; servers shall convert to UTC before emitting. Fractional seconds are optional and preserved as sent. All timestamps in this specification use this schema.
    - `distributionIds` Uuid[]: Array of TEA Component Release distributions that this TEA Artifact applies to. If absent or empty, the TEA Artifact applies to all distributions.
    - `formats` ArtifactFormat[], required: List of objects with the same content, but in different formats. The order of the list has no significance.
      - `mediaType` string, required: The Media Type of the document. A media type shall appear at most once across the `formats` of a single TEA Artifact revision, so that every format can be selected unambiguously by media type when downloading its content or its signature.
      - `description` string: A free text describing the TEA Artifact
      - `url` string, uri: External download URL for this format of the TEA Artifact. This is always a location outside the TEA API. When present, clients shall retrieve the content from it. When absent, the TEA server hosts the content itself and clients shall retrieve it from the artifact download endpoint, `/artifact/{uuid}/{artifactVersion}/download`, selecting this format by its `mediaType`. `url` and `signatureUrl` should be stable URLs. Servers should not publish pre-signed or otherwise expiring URLs in them. A server that serves content from expiring storage links shall omit them and answer from the download endpoints, with `302` where the bytes live elsewhere. A TEA access token is sent only to the TEA server's own API base URL, never to an external URL. External locations are either openly accessible or require credentials the client arranges separately. External `url` values are part of the published artifact revision. Changing `url` shall create a new artifact revision, even when content bytes and checksums are unchanged. The server shall preserve the URLs published on each historical artifact revision. If a Collection adopts that new revision, collection versioning follows `collection.version`. Byte stability for content retrieved through the server's download endpoint follows `artifact.version`. The TEA server does not control the bytes behind an external `url`, so for every format that has a `url` the server shall publish at least one checksum: the checksums are the integrity statement for the revision. Content retrieved from `url` that does not match them is not the content of that revision.
      - `signatureUrl` string, uri: External download URL for a detached signature of this format of the TEA Artifact. As with `url`, this is always a location outside the TEA API. When present, clients shall retrieve the signature from it. When absent, clients shall retrieve it from the artifact signature download endpoint, `/artifact/{uuid}/{artifactVersion}/signature/download`, selecting this format by its `mediaType`; that endpoint returns `404` when no signature is published for the format. The same access-token, stable-URL, and revision rules as for `url` apply to `signatureUrl`. Byte stability for signature retrieval through the server's signature download endpoint follows `artifact.version`. This specification does not define which signature technology is used, nor model the signing algorithm, key, or certificate chain.
      - `checksums` Checksum[]: Checksums for this artifact format's content bytes (the payload retrieved from `url` or from the artifact download endpoint for this `mediaType`), not the detached signature. When present, `checksums` shall contain at least one entry. When `url` is present, `checksums` is required. Those checksums are the integrity statement for that external `url`. Content retrieved from `url` that does not match them is not the content of that revision. Published checksums shall be calculated over the artifact format's bytes before HTTP content coding is applied. Clients verifying them shall first remove any HTTP transfer coding and content coding, and shall not otherwise transform or canonicalize the artifact bytes. An artifact that is itself compressed, such as a `.gz` file, stays in that form. The TEA servers shall not declare the artifact's own compression as HTTP content coding, because clients would then remove it and the checksum would not match.
        - `algType` 'SHA-1' | 'SHA-256' | 'SHA-384' | 'SHA-512' | 'SHA3-256' | 'SHA3-384' | 'SHA3-512' | 'BLAKE2b-256' | 'BLAKE2b-384' | 'BLAKE2b-512' | 'BLAKE3', required: Checksum algorithm
        - `algValue` string, required: Lowercase hexadecimal digest value for `algType`. Do not use Base64 or uppercase hex.

## Other responses

- `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.

## Changes

- **2026-09-23** `c69063d1dfff`: 2 info
  - api tag `TEA Collection` added
  - api tag `TEA Product Release` removed
- **2026-09-23** `e476cd640edc`: 3 info
  - api tag `TEA Product Release` added
  - api tag `TEA Collection` removed
  - the `artifacts/items/formats/items/` response property dependentRequired was added for the status `200`: when `url` is present, `checksums` are required
- **2026-09-23** `e364970b951f`: 2 info
  - api tag `TEA Collection` added
  - api tag `TEA Product Release` removed
- **2026-09-22** `d56f299e3e44`: 1 info
  - api operation id `getLatestCollectionForProductRelease` removed and replaced with `getLatestProductReleaseCollection`
- **2026-09-20** `f698addb5d2b`: 9 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
  - …5 more

[Operation history](https://skmtc.dev/cyclonedx/apis/transparency-exchange-api/changes/productRelease/:uuid/collection/latest/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/fc55bb5dacdd?raw)