32
Rate limits, quotas, and backoff
Guides & tutorials2 min read
Design clients that behave well under a limit instead of around a number.
Nexis enforces limits at more than one layer: the API key you authenticate with and the individual tool a specialist calls both carry their own ceiling. Exact numeric thresholds aren't published in these docs; design your client to behave well under a limit rather than around a specific number.
Where limits apply
| Layer | Enforced by | What it bounds |
|---|---|---|
| API key | BFF | Hashed, scoped, revocable keys carry their own expiry and rate limit |
| Tool call | Tool gateway | Every registered tool declares its own rate limit alongside its risk tier and scopes |
| Shared infrastructure | Redis | Locks, fanout, and rate limiting for the local data plane |
Handle throttling like any other transient failure
- Back off and retry with jitter instead of a fixed interval. A tight retry loop against a throttled endpoint just extends the outage for your own client.
- Reuse the same idempotency key on a retried run creation call; a throttled request never reached completion, so it is safe to resend.
- A specialist agent that keeps hitting a tool's own rate limit is a signal to slow the run down, not to route around the gateway.
Numbers are not published here
These docs establish that API keys and individual tools each carry a rate limit, but they don't enumerate the exact ceilings. Treat any concrete threshold you observe as account- or tool-specific rather than a platform-wide constant, and confirm it with the platform team before hardcoding it.
Scope keys narrowly to reduce blast radius
- Prefer a narrowly scoped API key per integration over one broad key shared across services. That way a limit hit on one integration does not stall the others.
- Expire and rotate keys instead of relying on a single long-lived credential; expiry is part of the same key contract as the rate limit.
Was this page helpful?
Edit on GitHub