Product API

Runs transactions. Base path /v1.0, versioned in the path, API-key authenticated.

Use it to issue, verify, check status and revoke. Use the Management API to configure the resources these operate on.

Operations

Full reference.

Response shape

{ "data": { } }

The Product plane keeps the data envelope. It is not the Management resource envelope, and that is deliberate: a runtime response is a transaction result, not a configuration resource with identity, an entity tag and audit stamps. Giving it those would be shape for its own sake.

Idempotency

Mutating operations accept Idempotency-Key:

POST /v1.0/credentials/issuance
Idempotency-Key: order-4417

Same key, same payload: the original result is replayed. Same key, different payload: 409.

This is what makes retrying a timed-out request safe. Without it, a network timeout on an issuance leaves you unable to tell whether a credential was issued, and retrying risks issuing a second one.

Use a key derived from your own business identifier, not a fresh UUID per attempt — a new UUID on each retry defeats the mechanism entirely. See idempotency.

Where the holder takes over

Two operations end in a state that is waiting for a person:

• issuance reaches awaiting_wallet
• verification reaches pending

These are correct terminal states for an integration with no wallet in the loop, not failures and not timeouts. A credential nobody accepted is not held by anyone; a verification nobody responded to has no result.

Design for it: show the user something, poll or wait for the state to change, and set your own overall deadline.

Versioning

/v1.0 is canonical, /v1 is a supported compatibility alias — same handler, same behaviour, same idempotency identity, so a retry that starts on one and finishes on the other still deduplicates. No api-version parameter. See API versioning.

Next

• Idempotency
• Verification
• Credential status