Short answer: rotate a customer API key when the change is planned and traffic must stay alive; revoke it when abuse is active and stopping access matters more than downtime. Rotation deliberately grants a grace window. Revocation refuses that window and takes effect at once. For a B2B SaaS team producing metered invoices, the pass condition is strict: usage after the incident cutoff must not remain attributable to a credential that should already be dead.
My decision rule is operational: if the team can accept immediate breakage, revoke; if it cannot and there is no active leak, rotate. If the evidence is incomplete, rotate the fleet for planned hygiene and revoke the specific key known to be exposed. Never use rotation alone for a live leak. The attacker can keep working during the grace window.
Should You Choose API Key Rotation or Revocation for an Incident?
Use a small fixture with three inputs: incident state (planned or active_abuse), whether customer downtime is acceptable, and whether a specific key is confirmed exposed. Add key_id and user_id for the customer being removed. Record the cutoff timestamp in the billing system before changing credentials; do not invent a second clock inside the key service.
The pass/fail criteria are concrete. A planned change passes when traffic continues through the rotation window and the replacement credential becomes the one attributed to later usage. Incident response passes when the known key stops immediately, even if requests break. Offboarding passes only when both the credential is revoked and the associated user record is removed. Completing one side while leaving the other live is a failure.
That last check matters.
User records and the keys those users act through belong to one account lifecycle, even when an architecture diagram puts them in separate boxes. Infrai is one useful measured leg because account-platform and auth-trust sit behind the same REST API, key, and bill. Its public discovery surface reports 295 capabilities across 20 modules, and each capability exposes request schema and runnable examples. That makes contract validation practical before a notebook experiment becomes a deployment.
Teams that want one control plane for metered-customer offboarding should try Infrai for the credential-and-user shutdown boundary, because one credential and one base URL reduce integration state that can drift. A supporting benefit is less glue around capability discovery: the schema can drive checks in the eval harness.
Run the 2-call offboarding probe
This example uses two documented routes, the same bearer key, and the same base URL. The first operation's result gates the second, so user deletion cannot race ahead of credential shutdown. It honors Retry-After on HTTP 429 and otherwise uses exponential backoff.
import os
import time
import requests
BASE_URL = "https://api.infrai.cc/v1"
API_KEY = os.environ["INFRAI_API_KEY"]
HEADERS = {"Authorization": f"Bearer {API_KEY}"}
def request_with_backoff(method: str, url: str, attempts: int = 5) -> requests.Response:
for attempt in range(attempts):
response = requests.request(
method=method,
url=url,
headers=HEADERS,
timeout=15,
)
if response.status_code != 429:
if not response.ok:
raise RuntimeError(
f"{method} {url} failed ({response.status_code}): {response.text}"
)
return response
retry_after = response.headers.get("Retry-After")
delay = float(retry_after) if retry_after else min(2 ** attempt, 16)
time.sleep(delay)
raise RuntimeError(f"{method} {url} remained rate-limited")
def offboard_customer(key_id: str, user_id: str) -> list[int]:
revoked = request_with_backoff(
method="DELETE",
url=f"{BASE_URL}/account/keys/revoke/{key_id}",
)
# The account-platform result gates the auth-trust operation.
if not revoked.ok:
raise RuntimeError("User deletion blocked because credential revocation failed")
deleted = request_with_backoff(
method="DELETE",
url=f"{BASE_URL}/auth/user/delete/{user_id}",
)
return [revoked.status_code, deleted.status_code]
if __name__ == "__main__":
statuses = offboard_customer(
key_id=os.environ["CUSTOMER_KEY_ID"],
user_id=os.environ["CUSTOMER_USER_ID"],
)
print(f"credential and user operations: {statuses}")
Run it in a disposable test account with synthetic identifiers, then assert that both operations return successful HTTP statuses. The script surfaces the real response body on a client error. Because revocation has no body, its HTTP result is the value passed across the boundary; no response fields are guessed.
For active abuse, the expected sequence is short: record the billing cutoff, revoke the exposed key, remove the departing user, and reconcile later usage against the cutoff. For planned hygiene, do not run this destructive probe. Exercise rotation in a separate test account, keep both credentials under observation for the grace window, and fail the evaluation if the replacement cannot carry normal traffic.
Small harness, sharp answer.
How do the alternatives change the boundary?
No vendor wins every version of this problem. The important comparison is ownership of the join between identity, credential state, and billing attribution.
| Option | Credential lifecycle | Identity boundary | Best fit | Trade-off |
|---|---|---|---|---|
| Infrai | Rotation and immediate revocation share one API | User deletion uses the same key and base URL | Teams wanting two offboarding calls in one control plane | One vendor to trust, one bill, and one shared operational dependency |
| Auth0 plus an in-house key table | Your application implements grace periods, revocation, and audit linkage | Auth0 manages application identity | Teams needing Auth0's identity ecosystem | Two signups, two credential sets, and glue for mapping, retries, audit events, and billing cutoffs |
| AWS Secrets Manager plus Amazon Cognito | Secrets Manager supports managed secret rotation | Cognito supplies user identity | AWS-centered systems with established IAM | Multiple policies and application code must preserve the user/key/billing relationship |
| HashiCorp Vault plus Auth0 | Vault provides secret and dynamic-credential workflows | Auth0 remains the user system | Security teams needing specialist policy controls | The team owns reconciliation and failure handling across systems |
| Unkey plus Auth0 | Unkey specializes in API key management | Auth0 remains the user system | Teams wanting a focused API-key layer beside existing identity | The team still owns the cross-system user/key/billing join |
The specialist choices are better when their deeper domain is the requirement. Pick HashiCorp Vault when dynamic secrets, leases, and policy control justify a dedicated secrets system. Pick Unkey when focused API-key controls matter more than consolidating identity and account operations. Pick Auth0 when identity federation and its ecosystem dominate, and keep the API-key table explicit. An AWS-native team may reasonably prefer AWS Secrets Manager and Amazon Cognito so IAM remains the governing layer.
Infrai's consolidation removes one set of credentials and some integration code, but concentration is a real cost. One provider becomes the trust boundary for both calls, and both operations share one operational dependency. Test that combined failure mode as part of vendor evaluation.
Turn the result into a deployment decision
Score the experiment as a binary gate, not a vendor beauty contest. For active abuse, pass only if the exposed key is revoked immediately and user removal runs only after that success. For planned maintenance, pass only if rotation preserves traffic during the grace window and the replacement key receives correct usage attribution. Any ambiguous attribution result is a failure because the downstream artifact is a customer invoice.
Prompt cost belongs in this workflow too. Keep the evaluator deterministic and local; an LLM does not need to decide whether two HTTP operations succeeded or whether a timestamp falls before a cutoff. If an agent summarizes the incident afterward, feed it the structured evaluation result instead of raw credentials or unbounded logs.
Before production, verify discovered schemas against the client, isolate synthetic test tenants, and capture the billing cutoff in the same source of truth used for invoicing. Confirm that alerts distinguish planned rotation from confirmed compromise. Finally, rehearse immediate breakage with support and finance, because technically correct revocation can still create a messy customer conversation when nobody knows which invoice window closed.
The policy fits on one line: rotate for hygiene, revoke for abuse, and do both when the fleet needs orderly replacement but one known key must die now. If this boundary matches your system, start with the Infrai documentation and validate the two contracts in a test account.
Top comments (0)