Broker API rate limits: a checklist for trading teams

Find the limits that actually apply

What happens when the broker returns 429s during the open? Your system should slow the affected traffic without losing track of orders or blocking higher-priority work. Start by finding out which limit was reached, because a single API can enforce several quotas at once.

Limits may apply per account, API key, client application, IP address, endpoint or connection. They may also be shared across a group of accounts or reset on a rolling window rather than at a fixed minute boundary. A documented limit of 10 requests per second does not tell you whether ten requests can arrive together, or whether order entry and market data consume the same allowance.

Check the broker's documentation and response headers, then confirm behaviour in a low-risk test environment. Record the unit, scope, window, burst allowance and reset signal for every relevant limit.

Note whether the broker sends a 429 response, a vendor-specific error, a Retry-After header, or a connection close. The public coverage at Trading Technology can help teams keep broker platform and infrastructure changes in view, but your own integration contract is the source for operational settings.

The table gives typical market ranges, not guaranteed allowances or audited figures for a named provider. Actual quotas vary widely by broker, account tier, region and product. Use it to identify values worth checking, not to set production limits without verification.

Some providers count a batch as one request; others count each item. Some weight expensive queries more heavily. Test the assumptions that affect your traffic model rather than relying on the HTTP request count alone.

Separate traffic by operational value

Put order entry, cancels, risk checks, account reads and historical data into separate traffic classes. They do not have the same failure cost.

If a shared queue fills with chart history requests, a cancel may wait behind work that can be delayed. A priority queue or separate concurrency pools can prevent that, provided the broker's own quota is also shared fairly.

Keep headroom. If a verified limit is 10 requests per second, do not configure every service to send 10. Start at a lower sustained rate, perhaps 70 to 80 per cent of the confirmed allowance, and reserve capacity for bursts and recovery. The right margin depends on how tightly the broker enforces the window and how much traffic other applications share.

Use a token bucket or leaky-bucket limiter at the point where requests leave your platform. A token bucket allows a defined burst while controlling the longer-term rate. A leaky bucket releases requests at a steadier pace.

Either is more predictable than letting every worker make independent decisions. If several pods or regions share one broker credential, their limits need a common coordinator or allocated per-instance budgets.

• Give cancels and risk-reducing actions a higher queue priority than reports and historical queries.
• Set queue limits as well as request rates. An unbounded queue turns a short throttle into a long delay and a memory problem.
• Attach a deadline to each queued request. Drop stale reads, but never silently discard an order action.
• Expose queue age and depth by traffic class. A low request rate can still conceal a growing backlog.

Check whether the broker applies independent limits to order operations and data calls. If it does not, keep a shared budget and reserve part of it for critical actions. If the interface and operational terms leave the scope unclear, ask the broker before a peak session. Do not infer separate quotas from separate URLs.

Make retries safe and bounded

A 429 is a flow-control signal, not an invitation to retry immediately. Honour Retry-After when present. If it is absent, use exponential backoff with jitter so that clients do not all wake and resend on the same boundary.

A practical starting policy is a 100 to 250 millisecond base delay, doubling on each attempt, with random jitter and a cap of several seconds. Tune it to the broker's reset window and the request's deadline.

Retry only when the operation is safe to repeat. A timed-out order submission may have reached the broker even if your client did not receive the response. Resending it can create a duplicate order. Use a stable client order ID or idempotency key where the broker supports one, and query by that identifier before deciding whether to submit again. If there is no idempotency mechanism, treat an ambiguous timeout as an unknown order state and reconcile it before retrying.

Backoff reduces pressure. Idempotency prevents a timeout from becoming a second order.

Distinguish errors before deciding what to retry. A 429 usually calls for slower traffic. A 5xx may be transient, but repeated retries can amplify a broker outage. A validation error will not be fixed by waiting. Use a small retry budget, such as two or three attempts for eligible reads, and stop when the request deadline expires. Order actions need operation-specific recovery rules, not a generic retry wrapper.

1. Classify each endpoint as safe to retry, unsafe to retry, or safe only with an idempotency key.
2. On 429, pause the relevant scope, such as an account or API key, rather than only the worker that received the response.
3. Apply exponential backoff with jitter, honour Retry-After, and cap attempts and total elapsed time.
4. On an ambiguous order timeout, check order status or reconcile open orders before resubmitting.
5. On repeated 5xx responses, open a circuit breaker for the affected operation and alert the on-call team.
6. Record each attempt, response code, delay and final outcome against a request or order correlation ID.

Throttle locally and observe the broker response

Client-side controls should reduce demand before the broker has to reject it. Set a sustained rate and a burst limit per scope, then adjust only from evidence.

A controller can reduce its send rate after 429s and increase it gradually after a stable period. Avoid aggressive automatic increases: traffic from another application using the same credential can make your measurements misleading.

Measure request rate, 429 rate, latency, retries, timeouts and queue age. Break these down by endpoint, account, API key and application instance. Keep separate counts for first attempts and retries; otherwise a retry storm can look like a healthy increase in throughput. Alert on sustained 429s, rising queue age and an unusual difference between submitted orders and acknowledged orders.

Rate limits are not the only constraint. Connection limits, concurrent request caps, WebSocket subscription quotas and message rates may apply as well.

A WebSocket can reduce polling, but too many subscriptions or reconnect loops can still hit a separate control. Add jitter to reconnect timing, restore subscriptions in batches and track the last confirmed sequence or update where the feed supports it.

Use metrics to answer operational questions, not just to fill a dashboard. Can the on-call engineer see which quota is exhausted? Can operations distinguish a delayed read from an unconfirmed order? Is there a clear way to pause low-priority traffic without disabling order management? The platform reporting at Trading Technology offers industry context, while these answers should come from your own service telemetry and runbooks.

Run this week's check

Keep the review small enough to finish and broad enough to catch the failure paths. Assign an owner from engineering or operations, and include the person responsible for the broker relationship if quota details are missing.

1. Inventory every broker endpoint used in production and group calls by account, credential, IP and application.
2. Compare documented limits with observed peak rates over the last 30 days. Include order bursts at the open, retries and traffic from batch jobs.
3. Confirm how 429s and other throttle responses appear in logs, including headers, reset times and broker-specific error bodies.
4. Check that order submits use stable identifiers and that ambiguous timeouts trigger reconciliation rather than blind resubmission.
5. Set local rate and burst budgets with explicit headroom. Split critical order and cancel traffic from deferrable reads where the broker's quota model allows it.
6. Run a controlled test in a sandbox or approved test account. Exercise 429s, timeouts, delayed responses and a queue backlog; confirm that alerts fire and recovery is bounded.
7. Write the recovery steps into the on-call runbook, including who can pause traffic, how to inspect unknown orders and how to contact the broker.

Review the results after the next busy session. If requests remain below quota but order acknowledgements slow down, investigate latency and concurrency limits as well as rate. If several services share credentials, repeat the review with their combined traffic. The mistake most readers will still make is treating a 429 as a worker-level problem, when the exhausted budget is often shared across the whole application.

#broker API throttling #exponential backoff #HTTP 429 handling #API request queues #order management API #rate limit monitoring #idempotent order submission #broker connectivity