Measure broker API rate limits before bursts hit

A 429 response is not a rate-limit strategy. It is evidence that a client has already reached a boundary, and the response alone rarely tells an operations team whether the cause was a burst, a noisy account, a retry loop or a vendor-wide capacity problem. The useful question is how much demand is approaching that boundary, how quickly it can be shed, and which trading workflows must keep moving.

Broker APIs often apply limits at several layers: per credential, account, IP address, endpoint or concurrent connection. A limit may use a rolling window, a token bucket or a fixed interval.

A starting planning range across broker and vendor APIs might be 5 to 50 requests per second per credential, with lower limits on selected endpoints, but the actual policy is provider-specific and can change. Treat published quotas as constraints to test, not as a capacity guarantee.

Know which limit you are measuring

First, map each API operation to its likely quota and business purpose. A quote snapshot, account query, order submission and order-status check may all have different costs. Some APIs count requests, while others apply separate limits for order entry, cancellations or concurrent sessions. A client that groups everything under one global request counter cannot explain which workload consumed its budget.

Record the response code, endpoint, credential or account identifier, request weight if supplied, and any limit headers. Common headers expose a remaining quota, a reset time or a retry delay. Capture them on successful responses as well as errors. If the provider supplies no headers, infer pressure from 429 frequency and controlled tests in a non-production environment. Do not assume a 429 from one endpoint means every endpoint is blocked.

Separate hard limits from service health. A 429 usually signals a quota boundary, while a 5xx response points to a server-side failure, although providers do not always follow that distinction perfectly. Read the response body and provider guidance. A timeout is more ambiguous: an order may have been accepted even if the client never received the acknowledgement. Blindly repeating an order submission can create a duplicate unless the API supports idempotency keys or the client first reconciles order state.

For broader infrastructure coverage, Trading Technology's infrastructure reporting sits alongside the operational details teams need to track internally: request weights, burst allowances and recovery behaviour.

Measure pressure, not just 429s

Count attempts and successful responses separately. For each endpoint and account cohort, track requests per second, 429s as a share of attempts, timeout and 5xx rates, retry volume, and the fraction of available quota consumed.

Add queue depth and oldest-item age. A low 429 rate can still hide a near-saturated client if requests are queuing before they reach the broker.

Use a short interval for burst detection and a longer one for trend analysis. One-second or five-second buckets reveal spikes that disappear in a minute-level average.

Keep p50, p95 and p99 latency for both the client queue and the full API round trip. Tag every measurement with the operation and outcome. Without those dimensions, an apparent increase in latency could be slow account reads rather than order acknowledgements.

Useful operational signals include:

• Quota headroom: available requests divided by the limit over the relevant window, where the provider exposes both values.
• Retry amplification: all attempts divided by original logical requests. A rise from 1.0 to 1.5 means each business request is generating half an extra API call on average.
• Queue age: the time between a task becoming eligible and the client sending it. Track the oldest task as well as the median.
• Order-path health: submission and acknowledgement latency, rejected submissions, and unresolved timeouts. Do not merge these with read-only traffic.

Set alerts on combinations rather than a single threshold. For example, sustained quota use above 80 per cent alongside rising queue age is a reason to throttle proactively, even before 429s appear. The 80 per cent figure is a starting operating threshold, not a universal rule. Test it against burst size, provider reset windows and the recovery time your workflows can tolerate.

Backoff is a traffic-control loop

When a request is rejected, retrying immediately adds load at the point of maximum pressure. Use exponential backoff with jitter for retryable reads and other safe operations. A typical schedule might start at 200 to 500 milliseconds, multiply the delay by roughly two after each failure, and cap it at 5 to 30 seconds. Randomise the delay so a group of clients does not wake and retry together.

Respect a valid Retry-After value in preference to a locally calculated delay. Set a maximum attempt count and a total retry time budget.

When either runs out, send the task to a delayed queue or mark it for operational review rather than retrying indefinitely. For non-idempotent operations, retry only when the API's idempotency mechanism and the client's reconciliation logic make the outcome safe.

Backoff needs a reset condition. If a client clears its failure counter after one success, it may quickly return to full speed and recreate the burst. A gradual recovery ramp, such as increasing the allowed send rate in steps over tens of seconds, can be safer. Tune the interval to the provider's documented reset behaviour and to how quickly the queue is growing. If the queue continues to age during recovery, the ramp is too fast or incoming demand still exceeds capacity.

Distinguish client-side throttling from server-side backoff. A token bucket can smooth local bursts, while a concurrency limit can prevent too many slow requests being in flight at once.

Both controls protect the client and the provider, but neither makes extra quota appear. Measure whether limiting concurrency reduces timeouts, and watch for a backlog that simply moves from the network layer into an internal queue.

Throttle by business priority

A single queue with first-in, first-out scheduling lets routine polling crowd out time-sensitive actions. Allocate request budgets by workload and account.

Order submission, cancellation and risk controls usually need a protected share; account refreshes, historical queries and non-essential analytics can use spare capacity or be delayed. The exact order of priority depends on the firm's controls and the broker's API contract.

Make the policy explicit. For example, reserve a share of the client-side budget for order-path traffic, cap low-priority polling, and stop optional work when the oldest critical task exceeds its latency threshold.

Apply limits per account as well as globally. A single high-activity account should not consume the entire shared allowance if other accounts rely on the same credential.

Before production, check what happens when limits collide:

• Can a cancellation still be sent when quote or account queries have exhausted their budget?
• Does a circuit breaker pause only the failing endpoint, or does it block unrelated operations too?
• Can queued requests expire or become stale before dispatch, especially price-sensitive reads?
• Do operators have a clear view of which account or service is consuming capacity?

These controls need a defined failure mode. Dropping stale market-data refreshes may be acceptable; silently dropping a cancellation is not.

Preserve enough context to replay or reconcile deferred work, and make queue expiry visible in alerts and logs. Teams tracking broker technology and platform operations should still validate these behaviours against their own account topology and provider documentation.

Put a cost on excess demand

Rate-limit incidents consume more than API quota. Retries add load, queued work adds latency, and reconciliation creates operational effort. The ranges below are typical planning estimates across API implementations, not provider guarantees or audited results. Measure the local figures before setting service objectives.

Translate those costs into a capacity budget. Suppose a client sends 20 logical requests per second and its retries lift the attempt ratio to 1.5. It is now making 30 attempts per second, before polling or other services sharing the credential are counted. If the configured client limit is 35 attempts per second, only five remain for all other work. That is a fragile operating point even if the provider's published limit is higher.

Measure the cost of throttling too. A restrictive cap can lengthen queue age and delay useful work, while an overly generous one can trigger repeated rejection and recovery cycles. Compare the p95 age of each workload against its business deadline, then tune the budgets to keep critical work within its own limit. Report both the protected traffic and the work deferred, so an apparently healthy order path does not conceal a growing backlog elsewhere.

Validate limits without harming order flow

Do not discover production limits by sending bursts at live order endpoints. Reproduce request patterns in a sandbox where its limits are representative, then confirm production behaviour through conservative observation and provider coordination. Sandbox quotas may differ, so treat them as useful for client logic and less useful for estimating live capacity.

Use this numbered checklist before changing a client throttle:

1. Inventory limits: document endpoint, credential, account, request weight, concurrency cap, reset window and provider response headers.
2. Baseline demand: collect one-second and five-second request rates, p95 and p99 latency, 429 rate, retry amplification and queue age for at least a representative trading period.
3. Classify operations: mark requests as order-critical, risk-critical, freshness-sensitive or deferrable. Record which calls are safe to retry and which require reconciliation.
4. Set budgets: configure per-endpoint and per-account caps below the known limit, with reserved capacity for critical operations and a documented reason for each margin.
5. Exercise failure paths: simulate 429 responses, delayed responses, timeouts and 5xx errors. Verify jitter, retry caps, idempotency and queue expiry.
6. Review recovery: check that traffic ramps back gradually, queues drain within service objectives, and alerts identify the endpoint and account behind the pressure.

Keep the dashboards at the same granularity as the control policy. If throttling acts per account but monitoring only shows a global average, an account-specific burst will be hard to detect. Revisit limits after endpoint changes, new account launches, a shift in polling frequency or a provider policy update. A small scheduled review catches quota drift before it becomes a live incident.

This week, instrument and chart per-endpoint retry amplification alongside queue age for one production API.

#broker API throttling #API rate limiting #exponential backoff #HTTP 429 #request budgets #order API reliability #retry logic #API monitoring