Skip to main content
Each API key may make up to 10 requests per second. Beyond that, requests return 429 with the standard error envelope until the next second’s budget opens up.

​
What the limit actually means

  • It’s per key, not per IP or per workspace. Two integrations sharing one key share one budget, which is the practical argument for one key per integration.
  • There is no daily quota. The limit is a rate. Stay under 10 in any given second and you can run at that pace all day.
  • Parallel workers count together. Five workers each making 3 requests per second on the same key will hit the limit constantly.

​
Staying under it

  1. Ask for more per request. Lists return 10 items by default but will give you up to 50. limit=50 cuts a bulk read’s request count by 5x. See pagination.
  2. Cache reads that rarely change. Your user list doesn’t change every second. Fetch it on startup or on an interval measured in minutes, not in a loop.
  3. Smooth your bursts. A client-side throttle (most HTTP libraries have one) turns a thundering herd into a queue, and a queue never sees a 429.
  4. Back off on 429. When you do hit the limit, retry with exponential backoff and jitter. Immediate retries from several workers arrive together and fail together.
Agents need this guidance too. If an LLM is generating your integration, or is your integration, tell it the budget is 10 requests per second. Otherwise it will happily write you a very polite, very fast polling loop. See Build with AI & agents.

​
Need more headroom?

If the limit is shaping your architecture, write to support+developers@quo.com and tell us what you’re building.