Rate limits

Exact API quotas are confirmed during provisioning, so this article focuses on the client behavior you should implement before go-live.

What to expect

• Burst traffic, bulk syncs, and tight polling loops are the most common causes of throttling.
• Read-heavy endpoints such as booking lookups can still be throttled if you call them per page view instead of batching or caching.
• Webhooks are often a better fit than repeated polling when another system needs timely updates.

Recommended client behavior

• Reuse access tokens until they expire instead of requesting a new token for every API call.
• Page through large result sets instead of refetching everything repeatedly.
• Cache read results where short-lived staleness is acceptable.
• Queue retries with jitter instead of retrying immediately.
• Respect 429 Too Many Requests and any Retry-After value if OmniLab sends one.
• Retry only idempotent reads automatically. Gate writes and cancellations carefully.

A safe retry model

1. If a request returns 429, back off immediately.
2. If Retry-After is present, wait at least that long.
3. Otherwise use exponential backoff with jitter.
4. Cap concurrent workers so one spike does not create a retry storm.
5. Surface a useful operator alert if throttling becomes sustained.

if response.status == 429:
  wait = retry_after_header or exponential_backoff_with_jitter
  retry_later()

Design patterns that reduce throttling

Related