API reference › API keys › Revoke key

Revoke an API key

Takes effect on the next request against that key — there is no un-revoke. Any member of the tenant can revoke any of the tenant's keys, including the one authenticating this call: rotating away from a key that just leaked is the normal case, not an edge case.

curl -s -X DELETE https://api.propgate.dev/v1/api-keys/019fcb02-... \
  -H "authorization: Bearer pg_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

{
  "data": {
    "createdAt": "2026-08-01T09:12:44.000Z",
    "createdBy": "you@example.com",
    "id": "019fcb02-...",
    "lastUsedAt": "2026-08-04T11:02:00.000Z",
    "name": "onboarding",
    "object": "api_key",
    "prefix": "pg_live_7c1d",
    "revoked": true,
    "revokedAt": "2026-08-05T14:03:00.000Z"
  },
  "error": null,
  "meta": {
    "alreadyRevoked": false
  }
}

meta.alreadyRevoked distinguishes the key you just revoked from one that already was. Both return the same 200 and the same key — revoking is idempotent — but a script re-running its own cleanup step deserves to know it was not the one that changed anything this time:

{
  "data": {
    "...": "..."
  },
  "error": null,
  "meta": {
    "alreadyRevoked": true
  }
}

Failure modes

{
  "data": null,
  "error": {
    "message": "no such api key"
  },
  "meta": null
}

A 404 covers an id that never existed and an id that belongs to a different tenant identically — a 403 for the second case would confirm the id exists somewhere, which is exactly the leak a 404 avoids.

Revoking your last active key is refused outright:

{
  "data": null,
  "error": {
    "message": "this is your last active api key; revoking it would lock you out of this API and there is no un-revoke. Create a replacement first."
  },
  "meta": null
}

There is no un-revoke, so honoring that request would strand the tenant with a valid key they cannot authenticate anything with, including a request to mint a replacement. Create the replacement first with POST /v1/api-keys, then revoke the old one.