api_key_revoked

HTTP 401   type: authentication_error   param: Authorization

{
  "error": {
    "type": "authentication_error",
    "code": "api_key_revoked",
    "message": "This API key was revoked on 2026-08-01. Issue a new key in the dashboard.",
    "param": "Authorization",
    "upstream": null,
    "doc_url": "https://docs.fiskhub.com/errors/api_key_revoked"
  }
}

What happened

The key is recognised, but it was revoked. Revocation is immediate and permanent — a revoked key is never reinstated.

This code is deliberately distinct from invalid_api_key: the key was real, which changes the diagnosis. It usually means one of

• a scheduled rotation the deployment did not pick up;
• a key revoked after a suspected leak;
• a device decommissioned along with its key;
• an old key still in a configuration file, a container image, or a stale environment.

Should you retry?

No. The key will never work again.

The fix

1. Issue a new key in the dashboard. It is shown once — store it immediately.
2. Deploy it wherever the old one lives. If it was baked into a device image, the fleet needs the new one before it can fiscalize.
3. Confirm nothing else is still using the old key. A revoked key failing across a fleet is the loud version of this problem; a revoked key failing on one forgotten machine is the quiet one.

curl -sS -o /dev/null -w "%{http_code}\n" \
  https://api.fiskhub.com/v1/companies \
  -H "Authorization: Bearer $NEW_KEY"

Sales made while the key was dead

Requests rejected at authentication were never fiscalized — there is no invoice, no ZKI and no receipt number for them.

If sales happened on the device during that window and were stored locally, submit them once the new key is in place, with their original occurred_at. FiskHub marks them as late delivery automatically.

There is a 30-day deadline

A sale more than 30 days old is rejected by the Tax Administration permanently. A key revoked without a replacement being deployed can quietly eat that window. Submit backed-up sales as soon as the new key works, not at the end of the month.

Rotating without downtime

Issue the new key, deploy it everywhere, confirm traffic is using it, and only then revoke the old one. Revoking first guarantees this error.

If a key has leaked, revoke immediately anyway — the sales made in the gap can be uploaded late, and a live key in the wrong hands cannot be.