Skip to main content
Requests are limited to 10 per second per IP address. Every request from the same IP address counts, whichever key it uses, so all of the bots and processes that send from one IP address share the limit; bots on different IP addresses do not. Over the limit, you’ll receive HTTP 429 Too Many Requests. If the response has a Retry-After header, wait that many seconds; otherwise back off (for example 1 second, with jitter) and retry. The body is:
Branch on the 429 status. TOO_MANY_REQUESTS is not one of the error codes the order and position routes return.

Handling a 429

  • A 429 records nothing, so retry the same request. For POST /trading/orders, keep the same request_id: the order was never accepted, so it cannot be placed twice.
  • Wait before retrying. Honour Retry-After when it is present; otherwise wait about a second.
  • Back off if 429s repeat. Wait a little longer on each consecutive 429 and add a small random delay (jitter), so several processes that were refused together do not all retry in the same instant.
  • Never retry instantly in a loop. An immediate retry is refused again.
  • A 429 is not a timeout. It is an answer, and it means the order was not accepted. No answer at all is different: check the order by request_id before resending, as in Order outcomes and retries.

Staying under the limit

  • Throttle on your side, once per IP address. Put every request through one client-side limiter shared by every process and thread that sends from the same IP address, such as a token bucket refilling at 10 per second or less. A limiter per process lets two processes on the same IP address spend 20 per second between them.
  • Avoid bursts. Firing many requests at once (placing a batch of orders, or polling every open order together) can exceed the limit even when your average is low. Spread them out.
  • Poll at a sensible cadence. Poll a new order every 500 ms to 1 second for the first few seconds, then every few seconds while it is still pending. Never poll in a tight loop.
  • More keys do not raise the limit. It is per IP address, so one key per bot is fine.

A request helper that retries on 429

Each example sends a signed request and, on a 429, waits the Retry-After seconds when the header is present and 1 second otherwise, longer on each repeat, plus up to 250 ms of jitter. Then it signs and sends the same request again, up to five attempts, and returns the last response. Every attempt is signed afresh, because the timestamp must be within 30 seconds of Splash’s clock. A failure with no response (a timeout or a dropped connection) is raised rather than retried: check the order by request_id first. The cURL, Python and TypeScript tabs reuse the variables and the sign() / request() helpers from the signed-order example; the Go tab is a complete program.