Key Revocation

Revocation permanently disables a credential or an entire IntegrationClient. It’s performed by an EPOS owner in Back Office Developer Tools.

Credential revocation vs. client revocation

• Revoking a credential disables one specific key. If the client has other active credentials, they keep working. This is what rotation does automatically to the old key.
• Revoking a client disables every credential that client has ever had, all at once. A revoked client cannot be re-enabled with new keys - it’s a terminal state, distinct from disabling a client, which is reversible.

What you’ll see after revocation

Any request using a revoked credential, or any credential belonging to a revoked/disabled client, gets:

{
  "error": {
    "code": "unauthorized",
    "message": "Authentication is required.",
    "details": {},
    "requestId": "req_..."
  }
}

401 unauthorized - the same response as a missing or malformed key. This is deliberate: EPOS doesn’t distinguish “your key is wrong” from “your key was revoked” in the response, so a caller can’t use the API to probe whether a specific key value was ever valid.

There is no automatic recovery

A revoked credential cannot be un-revoked, and there is no grace period. If your integration starts seeing 401 unauthorized unexpectedly on a key that was working, check with whoever manages your IntegrationClient before assuming it’s a bug in your code - it may have been revoked deliberately (security incident response, integration decommissioned, access review).

Building for this

• Handle 401 unauthorized explicitly in your integration - don’t let it retry forever assuming it’s transient (see Rate Limits for what is worth retrying).
• Alert a human when it happens unexpectedly, rather than silently going dark.
• Keep a documented process on your side for requesting a new key if yours is revoked.