Skip to main content

​
Rate Limits

All RxScale APIs enforce rate limits to ensure fair usage and system stability. The limits are per second — there is no separate per-minute quota. Every API uses the same throttle, so the rules below apply identically to all of them; only the number of requests per second differs.

​
How the limit is counted

The limit is keyed on the client IP address — never on your API key, organisation or user. Two API keys calling from the same outbound IP share one budget, and the same API key used from two different outbound IPs gets two separate budgets. If several of your systems share one outbound IP (for example behind a single NAT gateway), they share a single budget.
Rate limit counters are held in memory on each API server instance, and every API runs on multiple auto-scaled instances. The effective throughput you observe can therefore be somewhat higher than the documented limit, because your requests may be spread across instances. Treat the documented requests per second per IP as the guaranteed budget you should design against — do not rely on the extra headroom, as it varies with how traffic is distributed.

​
Limit per API

Limits are configured per API and may change. If your integration needs a higher limit, contact your RxScale account manager.

​
Rate Limit Response

When you exceed the rate limit, the API returns 429 Too Many Requests.
This is the one RxScale error response that is not JSON. A throttled request returns Content-Type: text/html with a short HTML error page, so response.json() will raise. Branch on the status code, not on the body.
No Retry-After and no X-RateLimit-* headers are sent. Because the window is a fixed one second, waiting one second is enough to get a fresh allowance — see Best Practices below.

​
Request Size Limit

Every RxScale API also caps the size of a single request body. A larger request is rejected before it is processed, with 413 Content Too Large:
JSON requests are far below this limit in normal use. If you are sending a very large batch, split it across several requests rather than growing a single one — see Batch operations below.

​
Best Practices

  • Use webhooks instead of polling for real-time updates. Register webhook subscriptions to receive notifications when orders or stock levels change.
  • Cache responses where appropriate. Product catalogs and SKU lists change infrequently.
  • Back off on 429. Wait at least one second — a full window — before the first retry, then increase the delay if you are still being throttled. Never retry immediately in a tight loop.
  • Check the status code before parsing the body. A 429 is HTML, so code that always calls response.json() will fail on exactly the response it was written to handle.
  • Spread a bulk job over time rather than firing a burst. All your systems behind one outbound IP share a single budget.
  • Batch operations when possible rather than making individual requests for each item.