Status and diagnostics
There are no outbound webhooks, no callbacks and no event stream. You learn outcomes by polling, and you debug them with the diagnostics timeline.
Verification result
Editions: SaaS · Self-hosted · Public
status is initiated, success, failure or expired; claims land in rawPresentation. See Verify a credential.
Issuance status
Editions: Public
{
"id": "3c9e…",
"status": "claimed",
"failureReason": null,
"claimedAt": "…",
"firstIssuedAt": null,
"lastIssuedAt": null,
"expiresAt": "…"
}
status | Means |
|---|---|
pending | offer created, wallet has not exchanged the code |
claimed | code exchanged, credential not yet fetched |
issued | credential delivered to the wallet |
expired | offer window closed |
failed | failureReason is set |
On SaaS and self-hosted deployments the equivalent view is the issuance history record in the dashboard.
Diagnostics timeline
Editions: Public
Available for both issuance offers and verifications. Query with page (0-based), limit (max 200) and order. The response holds a session plus events[] — each event carries eventType, severity, statusCode, errorCode, durationMs, requestId and traceId, covering the whole protocol run from issuance.offer.created or verification.initiated through to the final response.
Diagnostics are off unless DIAGNOSTICS_ENABLED is set; the endpoints return
404 when disabled. Payloads are redacted and truncated — tokens, credentials
and presentations never appear.
Correlating requests
Every response carries X-Request-ID. Send a W3C traceparent and its trace id is threaded through logs, queue jobs and diagnostic events — quote both when reporting a problem.