Read the headers on every response
The engine shipsX-RateLimit-Limit, X-RateLimit-Remaining, and
X-RateLimit-Reset on every 2xx. Log them or plumb them into your
metrics.
Batch before you loop
- 500 individual calc calls sent in a tight loop will 429 immediately (and burn 500 quota entries).
- One
/v1/calc/bulkcall with 500 rows uses one rate-limit slot and one quota entry. - Six
/v1/ratescalls for a sourcing comparison burn six slots. One/v1/comparecall fans out to all 6 origins server-side and uses one slot.
Concurrency ceiling
Cap outbound concurrency at 8 workers per key. At 8 concurrent workers averaging 500 ms per call, sustained throughput is roughly 960 rpm from the calling side, but only 60 rpm from the server side will succeed. The excess simply 429s. Prefer fewer workers with the built-in retry loop.Multi-key sharding
Rate limits are per key, not per organization. Split workloads by minting one key per workload:prod-quote-enginefor real-time UI quoting.ci-nightly-auditfor the nightly re-run.data-warehouse-etlfor the ETL that pulls rate snapshots.
Backoff with jitter
The SDKs implement exponential backoff with jitter automatically. If you are rolling your own:When to ask for higher limits
Ask when:- Your workload genuinely exceeds 60 rpm per key sustained, after moving to bulk and compare endpoints.
- You have a burst pattern that a longer window cannot absorb.