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
| Endpoint family | Limit |
|---|---|
| All read and generate endpoints (e-invoice, E-Way Bill, credential reads) | 60 requests / minute |
Credential management writes (POST and DELETE on /v1/gsp-credentials/*) | 10 requests / minute |
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{
"code": "request.rejected",
"message": "Too Many Requests",
"requestId": "…"
}Back off and retry — exponential backoff with jitter is the standard safe pattern (1s → 2s → 4s → 8s, capped). If you regularly hit the limit, talk to support about a higher tier rather than retrying tighter.
Headroom advice
- Cache OAuth tokens. A token request is a separate flow with its own quota at the auth layer; don't burn it minting a token per call.
- Don't poll the same endpoint in a tight loop. Cache responses on your side where you can — IRNs and EWBs don't change without a deliberate action on your part.
- Concurrency, not parallelism. If you have a burst of IRNs to register, pace them at a sustainable rate (one every ~1s for the default 60-rpm tier) rather than firing them in parallel.
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 configuration-only on our side — no code change for you.
Where to next
- Authentication — token lifecycle.
- Errors — every other error code you might see.