Authentication
Server-to-server calls authenticate with an API key in the X-API-Key header. A key is bound to one organization and to exactly one issuer or one verifier — there are no OAuth-style scopes.
curl "$LUTRAID_API/v1/organizations/$ORG/issuers/$ISSUER/create-credential-offer" \
-H "X-API-Key: $LUTRAID_KEY" \
-H "Content-Type: application/json" \
-d '{ "issuanceProfileId": "...", "data": [] }'
Key types
| Prefix | Grants | Use with |
|---|---|---|
iss_<keyId>_<secret> | one issuer | offer creation, issuance status |
ver_<keyId>_<secret> | one verifier | verification requests and results |
A key never grants access to a second issuer, verifier or organization; the wrong pairing returns 403.
Managing keys
Editions: SaaS · Self-hosted
Create and revoke keys in the dashboard, or through the organization API with a logged-in session — API keys cannot mint other API keys. The secret is returned once, at creation; it is stored only as a SHA-256 hash and cannot be read back.
There is no rotation endpoint. To rotate, create a replacement key, deploy it, then delete the old one.
On the public edition, keys are seeded from PUBLIC_EDITION_ISSUER_API_KEY and PUBLIC_EDITION_VERIFIER_API_KEY rather than managed over the API.
What is not enforced
The integration API is not rate limited and never returns 429. Usage is metered for billing on the SaaS edition, but requests are not throttled — build your own back-pressure if you fan out.