API Keys let your customers create credentials they can use to call your API — long-lived tokens with a recognizable prefix (e.g. sk_live_xxxxxxxxxxxx) that they paste into integrations, scripts, and CI. Authaz handles the issuance, hashing, scoping, and validation for you.
This is different from M2M. M2M is for your internal services (one credential per service). API Keys are for end users and customer integrations (potentially thousands of keys per application).
A key tied to a specific user. The key inherits whatever the user can do — same roles, same tenant, same permissions. Revoking the user revokes all of their keys. This is the right default for most products.
# Issued by the user from your dashboard, on their own behalfcurl -X POST https://your-app.authaz.io/api/v1/users/me/api-keys \ -H "Authorization: Bearer USER_ACCESS_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "name": "GitHub Actions deploy", "expiresAt": "2027-01-01T00:00:00Z" }'
If the key was revoked, expired, or never existed, you get { "active": false }. Cache positive results for 30–60 seconds to avoid hammering Authaz on hot paths — but invalidate on any 4xx from your downstream calls.
In multi-tenant applications, keys live inside a tenant by default — they can only access resources within that tenant, even if the issuing user belongs to several:
# Rotate — new value returned, old value invalid immediatelycurl -X POST https://your-app.authaz.io/api/v1/api-keys/{keyId}/rotate \ -H "X-API-Key: $AUTHAZ_API_KEY"# Revokecurl -X DELETE https://your-app.authaz.io/api/v1/api-keys/{keyId} \ -H "X-API-Key: $AUTHAZ_API_KEY"
For incidents, you can also revoke every key created by a specific user in one call — useful if their employee laptop walked off:
curl -X POST https://your-app.authaz.io/api/v1/users/{userId}/api-keys/revoke-all \ -H "X-API-Key: $AUTHAZ_API_KEY"
