Skip to main content

Rate Limits

Overview​

This API enforces throttling to ensure reliable and predictable access. Requests are executed synchronously and queued when multiple arrive.

Throttling Behavior​

  • Requests are processed synchronously
  • Additional requests are queued until processing becomes available.
  • If processing and queue capacity reaches its limits, new requests are rejected.

Rejections​

When the system cannot accept more requests into the queue, the API responds with:

  • HTTP 429 Too Many Requests

Client Integration Guidelines​

  • Synchronous Execution: Always wait for a response before sending the next request.
  • Rate Limiting: Pace your requests to avoid hitting queue limits.
  • Handling 429: Implement retry logic with a delay or exponential backoff.

Request Throttling

The request throttling is not a simple "X requests per minute" rate limit. Instead, it controls how many requests can be processed concurrently for each API user.

Default Configuration​

  • 1 request is processed immediately.
  • The next 20 requests can wait in the queue for up to 20 seconds.
  • The following 50 requests can wait for up to 500 milliseconds. If they cannot start processing within that time, they are rejected.
  • Any requests beyond these 71 total requests (1 processing + 70 waiting) are rejected immediately because the queue is full.

This mechanism prevents a single client from overwhelming the server while still allowing short bursts of traffic.

Example​

If 10 requests are sent at exactly the same time​

  • Request 1 starts immediately.
  • Requests 2–10 wait in the queue.
  • As each request finishes, the next request begins processing.
  • As long as each queued request starts within 20 seconds, all 10 requests succeed.

If 80 requests are sent simultaneously​

  • 1 request is processed immediately.
  • 20 requests wait for up to 20 seconds.
  • 50 requests wait for up to 500 ms.
  • The remaining 9 requests are rejected immediately because the queue is full.

Recommendation​

To avoid unnecessary complexity, we recommend sending requests one at a time (in series) from your side instead of sending many requests in parallel.

Since the API is configured to process only one concurrent request per API user, sending requests in parallel does not reduce the overall processing time in any meaningful way. The additional requests will simply wait in the queue until the previous request has finished.

Sending requests in series results in essentially the same total processing time while avoiding queue timeouts and rejected requests.