Skip to main content
Rate limiting on the Orgo API is per endpoint and per token, not a single global bucket. Most endpoints have no application-layer limit at all — they are only protected by platform-level infrastructure throttles. Limits exist on endpoints that are expensive (sending email, generating PDFs) or sensitive to abuse (login, OTP requests, impersonation).

How limits are applied

When an endpoint is rate-limited:
  • The limit is 20 requests per 60 seconds by default. Some endpoints set their own.
  • The bucket is keyed by the authenticated token (Api-Token or JWT), or by IP address for unauthenticated endpoints.
  • Hitting the limit returns 429 Too Many Requests with a Retry-After header telling you how many seconds to wait.
Read-heavy endpoints (GET /api/v1/users, GET /api/v1/events, etc.) are not application-rate-limited under normal circumstances — you can paginate freely.

Endpoints with explicit limits

Where a limit is not listed in an endpoint’s reference page, assume it is not application-rate-limited beyond platform protections.

The 429 response

Always honor Retry-After. Retrying inside the window will not succeed and only delays your overall throughput.

Designing for the limits

Many endpoints have explicit bulk variants: POST /api/v1/contacts/bulk-delete, POST /api/v1/waitlist_entries/bulk-approve, etc. Each bulk call counts as one request and is far cheaper than N individual calls.Prefer bulk endpoints over for entry in entries: api.delete(entry) loops.
itemsPerPage=100 is the cap. Setting it lower means more requests for the same data and a higher chance of tripping platform-level throttles. Use 100 unless you have a specific reason not to.
If you find yourself polling GET /api/v1/payments?status=PENDING every few seconds, subscribe to the product_payment.updated webhook instead. Webhooks deliver in under a second and cost no API calls. See Webhooks.
Do not call /api/v1/login-check before every request. Cache the JWT for its full ~11-day lifetime and only re-login when a request returns 401. The same applies to OAuth access tokens — cache and refresh on demand, never on every call.
For nightly data syncs, schedule them during your tenant’s off-hours. The platform handles concurrent tenants well, but a single integration making a thousand requests at noon still adds latency on top of normal user traffic.

Retry pattern

A safe pattern that handles both 429 and transient 5xx:
The same pattern in JavaScript / TypeScript:

Per-plan limits

There is no per-plan rate limit at the application layer today. Higher-volume plans get more generous platform-level concurrency budgets (more API workers, larger DB connection pools), but the per-endpoint application limits above are the same regardless of plan. If you have a use case that needs limits raised on a specific endpoint — high-volume webhook sender, large nightly export, etc. — contact support and we can adjust on a per-tenant basis.
  • Errors — the 429 envelope and full retry strategy
  • Webhooks — the cure for polling