CirculeID

API reference

Every endpoint, grouped by resource

Passports, events, credentials and resolution. The error contract, pagination and idempotency rules below apply uniformly across all four.

Base URL
api.circuleid.com
Version
/v1
Auth
Bearer

Definition

What endpoints does the passport API expose?

Four groups. Passport endpoints issue, read, update and version the product record. Event endpoints append and query EPCIS 2.0 supply chain events. Credential endpoints issue, verify and revoke signed claims. Resolution endpoints serve the public GS1 Digital Link path that a scanned data carrier follows.

If you have not read the API model yet, start there. The relationships between these four decide which one you should be calling, and that is the choice most integrations get wrong first.

Endpoints

Passports

The product record and its access policy. The gap endpoint is the one most integrations end up calling most often.
Passports endpoints
MethodPathPurpose
POST/v1/passportsIssue a passport against a GS1 identifier
GET/v1/passports/{id}Read the full record your key is entitled to
PATCH/v1/passports/{id}Update the record; material changes are versioned
GET/v1/passports/{id}/gapsFields the product group’s delegated act still requires
GET/v1/passports/{id}/versionsThe record’s version history
GET/v1/passportsList and filter passports in your tenant

Endpoints

Events

Append-only EPCIS 2.0 history. Use bulk for backfill; the single endpoint is optimised for latency, not throughput.
Events endpoints
MethodPathPurpose
POST/v1/eventsAppend one EPCIS 2.0 event
POST/v1/events/bulkAsynchronous bulk ingestion; returns a job
GET/v1/eventsQuery by object identity, business step or time
GET/v1/jobs/{id}Status of a bulk ingestion job

Endpoints

Credentials

Signed claims. Verification is available to anyone holding the credential and does not require these endpoints — they exist for convenience, not as a dependency.
Credentials endpoints
MethodPathPurpose
POST/v1/credentialsIssue a signed claim against a passport
GET/v1/credentials/{id}Retrieve a credential and its status
POST/v1/credentials/{id}/revokeRevoke; verification fails from this point
POST/v1/credentials/verifyVerify a credential you were presented

Endpoints

Resolution

The public path. No authentication, cacheable, and returning the tier the caller's credentials entitle them to.
Resolution endpoints
MethodPathPurpose
GET/01/{gtin}GS1 Digital Link resolution — the path a scan takes
GET/01/{gtin}/21/{serial}Resolution for an item-level passport

Conventions

Errors, pagination and idempotency

These apply across every endpoint above. Handling them once in your client is better than handling them per call site.
Conventions
# Validation errors return every problem at once.
HTTP/1.1 422 Unprocessable Entity
{
  "error": "validation_failed",
  "problems": [
    { "field": "materials[0].share", "constraint": "must sum to 1.0" },
    { "field": "carbonFootprint.method", "constraint": "required for this group" }
  ]
}

# Pagination is cursor-based: an offset would skip or repeat
# records as new events arrive while you are reading.
GET /v1/events?object=01/09506000134352&cursor=ev_8f21...

# Send an idempotency key on any write you might retry.
POST /v1/passports
Idempotency-Key: 6f1c9a7e-...   # a repeat returns the original result

Answers

Frequently asked questions

What does an error response look like?

A conventional HTTP status with a structured body naming the error, the field that failed and the constraint it violated. Validation errors are returned in full rather than one at a time, so a malformed product record surfaces every problem in one response instead of over five round trips.

How is pagination handled?

Cursor-based, not offset-based. Event histories grow while you are reading them, and an offset would silently skip or repeat records as new events arrive. The cursor is opaque and stable; pass the one returned by the previous page and stop when none comes back.

Are writes idempotent?

They can be, and should be. Send an idempotency key on any write you might retry, and a repeat with the same key returns the original result rather than creating a second passport or a duplicate event. Without one, a network timeout on a write leaves you unable to tell whether it applied.

What is the difference between reading a passport and resolving one?

Reading is authenticated and returns what your API key entitles you to. Resolving is what a scan does: public, anonymous, cacheable, and returning the tier the caller’s credentials allow — which for most callers is the public tier. They are separate paths with different performance and privacy properties.

Next step

Issue one against a sandbox key

The fastest way to judge an API is to send it a real product record and read what comes back.

Index