Revoke an API key.

DELETE

/account/api_key/{api_key_id}

const url = 'https://api.siteqwality.com/account/api_key/2489E9AD-2EE2-8E00-8EC9-32D5F69181C0';
const options = {method: 'DELETE', headers: {Authorization: 'Bearer <token>'}};

try {
  const response = await fetch(url, options);
  const data = await response.json();
  console.log(data);
} catch (error) {
  console.error(error);
}

curl --request DELETE \
  --url https://api.siteqwality.com/account/api_key/2489E9AD-2EE2-8E00-8EC9-32D5F69181C0 \
  --header 'Authorization: Bearer <token>'

The route and verb are unchanged, so the dashboard’s existing delete button keeps working, but the row is now kept and stamped revoked_at instead of being deleted. Revocation takes effect immediately: both the customer API and the ingest authorizers check revoked_at on every request. Keeping the row preserves the audit history of a credential that may have been used to change things.

Revoked keys disappear from GET /account/api_key, which is exactly what a delete looked like before.

Deliberately idempotent: an unknown or already-revoked id still returns 200. The M2M equivalent 404s on an unknown id, but this endpoint has always returned 200 for one (the DELETE simply matched no rows), and a caller that has been relying on that must not start seeing errors.

Authorizations

bearer_auth

Parameters

Path Parameters

api_key_id

required

string format: uuid

API key identifier

Responses

200

API key revoked (or was already)

401

Missing or invalid authentication

500

Internal server error