List sealed review submissions for a policy version
Every sealed review subject for one policy version, newest seal first.
RECORDS which submissions were sealed and in what order.
Order is an ordering fact about seals, not currentness. The first item is not necessarily the subject a reviewer should be looking at: currentness is the three-leg comparison of subject id, candidate revision and package digest, available on the detail route. Treating the newest seal as “the subject under review” without that check is the confusion sealed submissions exist to prevent.
Canonical component bytes are not included — ten canonical blobs per submission is not a list view. Fetch them from GET /v1/review-submissions/{submissionId}.
Authorizations
MeshQu API key passed as a bearer token: Authorization: Bearer mqu_…. Mint one in the console (Settings → API keys).
Tenant UUID for multi-tenant isolation. Required on all authenticated routes — validated before authentication (middleware/tenant.ts), so a missing or non-UUID header returns 400 (MISSING_TENANT_ID / INVALID_TENANT_ID) before the API key is checked.
Path Parameters
Policy id.
Policy version number.
x >= 1Response
Sealed submissions for one policy version, newest seal first. Order is an ordering fact about seals — it does not say the first item is CURRENT for the candidate.