Rate limits

Every route under /v1 shares one request budget. It is generous enough for a dashboard polling a fleet or for paging through a large list in one go, and every response tells you where you stand, so a well-behaved client never needs to hit it.

Read your budget

Every successful response carries three headers:

Header	Tells you
`RateLimit-Limit`	The size of your budget
`RateLimit-Remaining`	Requests left in it right now
`RateLimit-Reset`	Seconds until it is full again

The budget refills continuously, so a client that spreads its requests out can keep going indefinitely. Slow down when RateLimit-Remaining runs low, rather than waiting for a refusal.

Recover from a 429

A request over the limit is refused:

http

HTTP/1.1 429 Too Many Requests
Retry-After: 2

json

{
  "error": "rateLimited",
  "message": "too many requests; retry after 2s",
  "requestId": "7f1c0e2a-5b8d-4c1e-9a53-2f0d6f4b1e77"
}

Wait at least Retry-After seconds before the next request. Sending sooner is refused again and does not shorten the wait. The same value also arrives as X-RateLimit-After for older clients; prefer Retry-After.

Use fewer requests

Ask for big pages. limit=100 reads a long list in a fifth of the requests the default takes. See Errors, pagination and versioning.
Use counts that already exist. GET /v1/projects/{projectId}/fleet-health answers in one call what paging through every charger would.
Listen instead of polling. Live updates tell you when something changed, over one open connection, so you refetch only what moved. Webhooks do the same for your backend.