Status and diagnostics

Poll these endpoints for outcomes, or let webhooks tell you when a document is issued or a check completes. Debug failures with the diagnostics timeline.

GET/verifiers/{verifierId}/verifications/{verificationId}

Verification result

status is initiated, success, failure or expired; claims land in sharedClaims. See Verify a credential. In Intermediary mode sharedClaims is null and the values go to your result endpoint.

GET/issuers/{issuerId}/credential-offers/{offerId}/status

Issuance status

Request

curl "$LUTRAID_API/v1/organizations/$ORG/issuers/$ISSUER/credential-offers/$OFFER_ID/status" \
  -H "X-API-Key: $LUTRAID_KEY"
{
  "id": "3c9e…",
  "status": "claimed",
  "failureReason": null,
  "claimedAt": "…",
  "firstIssuedAt": null,
  "lastIssuedAt": null,
  "expiresAt": "…"
}
statusMeans
pendingoffer created, wallet has not exchanged the code
claimedcode exchanged, credential not yet fetched
issuedcredential delivered to the wallet
expiredoffer's 10-minute window closed
failedfailureReason is set

Poll a few seconds apart, or wait for the document.issued webhook.

GET/…/{id}/diagnostics

Diagnostics timeline

Available for both issuance offers and verifications. Query with page (0-based), limit (max 200) and order. The response holds session, events[], total, page, limit and order — each event carries eventType, severity, statusCode, errorCode, durationMs, requestId and traceId, covering the whole protocol run.

Request

curl "$LUTRAID_API/v1/organizations/$ORG/issuers/$ISSUER/credential-offers/$OFFER_ID/diagnostics?page=0&limit=50&order=asc" \
  -H "X-API-Key: $LUTRAID_KEY"

The same shape works on a verification: swap the path for .../verifiers/{verifierId}/verifications/{verificationId}/diagnostics.

Correlating requests

Every response carries X-Request-ID. Send a W3C traceparent and its trace id is threaded through logs and diagnostic events — quote both when reporting a problem.

Was this page helpful?