Rate limits

Each OAuth client has its own per-minute quota. Limits are partitioned on the token's azp (authorized party) claim — every client has an independent budget.

Defaults

Limits use a fixed-window counter that resets at the top of each minute (UTC). There is no queue — bursts beyond the limit are rejected immediately.

When you trip the limit

HTTP/1.1 429 Too Many Requests
Content-Type: application/json

{
  "object": "error",
  "code": "request.rejected",
  "message": "Too Many Requests",
  "httpStatus": 429,
  "requestId": "...",
  "traceId": "..."
}

Back off and retry — exponential backoff with jitter is the standard safe pattern. If you regularly hit the limit, talk to support about a higher tier rather than retrying tighter.

Headroom advice

• Cache tokens. A token request is a separate flow with its own (separate) limit at the auth layer; don't burn it issuing a token per call.
• Don't poll harder than you need to. For queued IRNs, our worker retries internally — polling every few seconds rarely helps. Use webhooks where possible.
• Batch where you can. GET /v1/einvoices?... returns paginated lists in a single call — prefer that over a loop of GET /{id} if you need many records.

Higher tiers

Volumes above 60 rpm are routine for high-throughput sellers. Email [email protected] with your expected traffic profile and we'll lift the limit per client; the change is config-only on our side.