API references

View as Markdown

Use this section to find each maintained HTTP surface. Evidence Gateway and its OID4VCI wallet delivery front end have fixed generated contracts. Registry Mint has a hand-authored reference. Relay generates its description from each adopter’s Registry contract.

Fixed generated APIs

Evidence Gateway’s routes are the same in every deployment, so one generated OpenAPI document describes the product. The development site reads it from the checked-out current source. Archived docsets read it from their release ref and hold it under the archive lock.

Evidence Gateway API documents the assertion, requester-scoped definition discovery, request batch, JWT VC issuer metadata, health, readiness, served-contract, and key discovery endpoints.

The document is generated with the other Evidence Gateway contract artifacts:

cargo run -p registry-evidence --example evidence-contracts -- --output "<directory>"

The committed copy lives in products/evidence/generated/, and root CI’s evidence-contracts job fails on any byte difference between the committed artifacts and a fresh generation. A running Evidence Gateway service publishes the same document at GET /openapi.json with no authentication required.

The separate evidence-oid4vci supporting service also has a deterministic, committed OpenAPI document. Root CI drift-checks it with the Evidence contract artifacts. Use the v0.21.0 OID4VCI OpenAPI artifact or render the current binary’s contract:

evidence-oid4vci openapi --output oid4vci.openapi.json

Rendered source

The card shows how the rendered Evidence Gateway artifact is selected and links to its operations. It is generated from src/data/openapi-sources.yaml.

Evidence Gateway API

registry-evidence

Owner: registry-evidence
Status: current checked-out source on the development site; release-ref source in archived docsets. A running Evidence Gateway service publishes the same generated document at `GET /openapi.json` with no authentication required.
Source: Pulled by `scripts/fetch-openapi.mjs` from `products/evidence/generated/registry-evidence.openapi.json` in the checked-out source for the development docset, or at the release ref selected by an archived docset. The document is generated by `cargo run -p registry-evidence --example evidence-contracts` and byte-drift-checked in root CI by the `evidence-contracts` job.
Pinned artifact: openapi/registry-evidence.openapi.json

Generated from src/data/openapi-sources.yaml.

Registry Mint: hand-authored supporting-service API

Registry Mint has a fixed HTTP surface but no generated OpenAPI artifact. Its configuration, token request and response, OAuth errors, discovery documents, key set, health, and readiness routes are documented in the Registry Mint reference.

Relay: one document per deployment

Relay has no product-level OpenAPI document to pin, so this site publishes none.

A Relay deployment serves data that its own registry.yaml declares. The compiler turns that document into the deployment’s OpenAPI 3.1.0 description, and relay serves the public projection of it at GET /openapi.json with no authentication required. The description names that deployment’s registry, its contract version, its base URI, and its own resources, operations, and statistical datasets. Deployments with different Registry contracts can produce different documents. Fetch the document from the deployment you are integrating with:

curl -fsS https://<relay-host>/openapi.json

Two projections are generated. The public projection is the artifact served at GET /openapi.json and it omits every surface the Registry marks operator-only. The full projection, openapi.full.yaml, is an operator-only artifact and is never served on that route.

What is fixed across every deployment is the route inventory, not the described data. Relay’s process router is a closed list:

Route	Method	Purpose
`/health`	GET	Process liveness
`/ready`	GET	Compiled Registry readiness
`/openapi.json`	GET	Public OpenAPI projection for this deployment
`/v2`	GET	Service metadata and the capability inventory
`/v2/resources`	GET	Declared resources
`/v2/resources/{resource}`	GET	One resource’s metadata
`/v2/resources/{resource}/records`	GET	Bounded record list
`/v2/resources/{resource}/records/{recordIdentifier}`	GET	One record read
`/v2/resources/{resource}/lookups/{lookup}`	POST	Declared named lookup
`/v2/resources/{resource}/searches/{search}`	GET	Declared named search
`/v2/artifacts/{artifactIdentifier}`	GET	One visibility-appropriate generated artifact
`/sdmx/v2/data/{context}/{agency}/{resource}/{version}/{key}`	GET	SDMX data with a series key
`/sdmx/v2/data/{context}/{agency}/{resource}/{version}`	GET	SDMX data with the key omitted
`/sdmx/v2/structure/{artefactType}/{agency}/{resource}/{version}`	GET	SDMX structure

A deployment cannot add a route to that list. What varies is which {resource}, {lookup}, {search}, and SDMX artefact identifiers resolve, which is exactly what the deployment’s own OpenAPI document tells you.

For the meaning of the response envelope, the access profiles that gate these routes, and the error taxonomy they share, use the reference and explanation pages rather than a rendered document: