API Reference

Both platform APIs publish an OpenAPI 3.1 document, and both are rendered here in full — every operation, every schema, with a request builder next to each one.

What these documents are

They are snapshots, taken from the running services when this site was built, and committed alongside the code. That is a deliberate trade.

A reference fetched live from the API would always be current — and would go dark whenever the API did, would depend on cross-origin permissions, and would leave every pre-rendered page empty. A committed snapshot builds offline, shows up in a diff when it changes, and carries the date it was taken.

The cost is that a snapshot can lag. A CI job re-fetches both documents on every change and fails when the committed copies no longer match the live services, so the lag is bounded by how often we build rather than by whether anyone remembered.

Authenticating

Both APIs are entered with a bearer token — a JWT in the Authorization header. The reference's Authentication panel takes one and keeps it for the rest of your visit, so you can try several endpoints without fetching it again. It stays in your browser.

Anonymous reads need none of this: resolution and public master data are open by design.

A token for right now

Sign in to Digital Data Management and your session already carries one. On the EPCIS API, GET /me/tokens hands back the tokens the current session holds.

Session tokens are short-lived, which is what you want while you are clicking around and exactly what you do not want in a running integration.

A token that keeps working

For an integration that has to run unattended — a connector, a nightly job, anything with no human at the keyboard — use an offline token. Open this in a browser, as the person the token will belong to:

https://id.epcis.cloud/connector-tokens/authorize

You are sent to the identity provider's login and consent screen, the exchange is protected with PKCE, and the offline_access scope is what makes the resulting token an offline one: it survives your session ending.

Three things to know before you start:

• The token is shown exactly once, on the page you land on, with a copy button. Nothing is stored on our side. Lose it and the only remedy is to run the flow again.
• Name it with the optional ?name= parameter — an offline token has no expiry to identify it by, so a label is how you tell later which integration holds which token.
• Revoke it from /connector-tokens when the integration is retired, or from the identity provider's own account console. A revoked token stops refreshing immediately.

About API keys

The EPCIS API also accepts an API-KEY header, and you will find it among the schemes. It is not the front door and we do not recommend starting there: a bearer token carries the same tenant and role claims the rest of the platform reasons about, and the offline flow above gives you one that lasts. The Digital Link Resolver accepts no API key at all.