Skip to content
FiskHub

rate_limited

HTTP 429   type: rate_limit_error   param: null
{
  "error": {
    "type": "rate_limit_error",
    "code": "rate_limited",
    "message": "Too many requests. Slow down and retry; see the Retry-After header.",
    "param": null,
    "upstream": null,
    "doc_url": "https://docs.fiskhub.com/errors/rate_limited"
  }
}

What happened

You crossed one of the request limits. Nothing was fiscalized — the request was refused before it reached any handler, so retrying it is safe.

The limits are deliberately high: 20,000 requests per minute per principal and per IP. They exist to stop a firmware loop with no backoff, not to meter trading. See rate limits for the full table.

Two much smaller budgets sit alongside them, and they are the likelier cause of a 429 in practice:

  • Sign-in — 30 per 15 minutes per IP.
  • Certificate upload and bulk device import — 60 per minute.

Should you retry?

Yes. Wait for Retry-After, then send the same request again with the same Idempotency-Key. Nothing was processed, so a retry is not a second sale.

HTTP/1.1 429 Too Many Requests
Retry-After: 27
RateLimit-Limit: 20000
RateLimit-Remaining: 0
RateLimit-Reset: 27

Honour the server’s number rather than guessing a shorter one, and add jitter — a fleet that all waits exactly 27 seconds comes back as one burst and trips the limit again.

The fix

If you are seeing this on POST /v1/invoices, something is looping. 20,000 requests a minute is far more than any real fleet of unattended devices generates, so the cause is almost always a retry without backoff, or a status poll in a tight loop after a retrying response. The sweep retries on its own every five minutes; checking once a few minutes later is enough.

For self-hosted deployments the limits are configurable, and can be switched off entirely — see rate limits.