An API response is one observation of exchange state. A dependable integration also handles missing responses, stale data, and reconciliation.
Map the interface
Begin with the venue's official documentation for the exact product you intend to use. Spot, futures, brokerage, and institutional APIs from the same company may have different authentication, identifiers, limits, and order types. A familiar company name does not mean examples from one API can be copied into another without checking.
Create an inventory of the endpoints and streams needed by the application. Separate public market reads, authenticated account reads, and actions that change orders or positions. Record the permission each requires and the source of truth used to verify the result. This turns an integration from a collection of successful requests into a defined state-management workflow.
Read limit scopes
A published request limit may apply per IP address, account, profile, API key, endpoint, or connection. Some venues count weighted units instead of raw requests, and some apply several windows at the same time. Check all applicable scopes before deciding how many workers or keys an application can use.
Coinbase Exchange documents public endpoint limits by IP and private endpoint limits by profile, with some endpoints having their own limits. It also documents HTTP 429 for exceeded REST limits. Those details illustrate why a universal 'requests per second' figure is incomplete. Consult the linked documentation for current values and the exact product's rules instead of treating an example budget as an entitlement.
Build a request budget
For a simple polling design, multiply the number of markets by requests per market per update, then by updates per minute. Twenty markets with two requests each every ten seconds produce 240 requests per minute, or four requests per second on average. An average alone does not describe the burst when all markets update at once.
The planner reserves a user-selected percentage of a supplied sustained limit for other activity. It compares polling load with the remaining capacity and reports the headroom. It omits weighted endpoints, shared IP traffic, bursts, retries, and venue-specific windows. Schedule work deliberately and budget those additional sources before translating a positive planner result into a production configuration.
Handle throttling
Use the API's documented response fields and retry guidance. A rate-limit response is different from an authentication error or an invalid order. Repeatedly retrying every failure can increase load while concealing the real problem. Place explicit bounds on retries and make the observed failure visible in logs and monitoring.
A delay strategy should account for concurrent workers as well as one request loop. If every worker retries at the same instant, a quiet period can end in another burst. Coordinate shared budgets and use the venue's supported recovery behaviour. Do not rotate identities or accounts merely to evade a service's documented restrictions.
Recover market data
A streaming connection reduces the need for repeated polling but introduces its own state. Some order-book feeds require a snapshot followed by incremental updates in sequence. Missing one event may leave a plausible-looking but incorrect local book. Follow the feed's documented snapshot and replay procedure, including its rules for overlapping updates.
On reconnect, determine whether local state can be resumed or must be rebuilt. Track feed timestamps and connection health so old data is distinguishable from a quiet market. A successful socket connection does not prove the local price or order book is current. Keep recovery tests focused on the exact channel, product, and message schema in use.
Follow an order
An accepted request may create an open order without executing it. An order can fill partially, remain open, be rejected, expire, or be cancelled under venue-specific rules. Store the exchange identifier and any client identifier, and reconcile the cumulative filled quantity rather than assuming one request produces one complete trade.
Cancellation has a race with execution. A cancel request sent while a trade is matching may arrive too late to prevent a fill. Account for fills that occur before cancellation becomes effective. The final state should come from authoritative order and fill records, with fees and remaining quantity included, not from the intention expressed by the last button clicked.
Treat timeouts carefully
If an order submission times out, the exchange may have accepted it even though the client did not receive a response. A timeout describes the communication outcome, not necessarily the business outcome. Immediately resubmitting can increase exposure if both orders are accepted.
Check the API's documented client-order-ID and duplicate-handling semantics. Where supported, use a stable identifier and query for the existing order before deciding what to do next. Do not assume every venue treats a repeated identifier as idempotent. Document unresolved states explicitly and stop new activity when uncertainty exceeds the application's limits.
Keep secrets server-side
Static HTML and JavaScript are delivered to the visitor and can be inspected. They are not an appropriate place for exchange signing secrets. An authenticated trading integration needs a controlled server-side component with permissions, logging, and secret handling suited to its task. This site's planner needs no API key and sends no requests to an exchange.
Before release, test precision rules, minimum size, symbol changes, clock requirements, rejected orders, partial fills, throttling, reconnects, and reconciliation after an interrupted request. Keep example responses separate from production observations. When documentation changes, record what was verified and which integration assumptions need another test.
Primary sources
Read the original documentation for product-specific details. Our examples simplify the arithmetic and do not reproduce all contract or service rules.
Work your own example
Plan polling volume against a request limit you supply. This simple model does not simulate burst limits or endpoint weights.
Open calculatorPrepared using AI-assisted drafting. No independent professional review or hands-on product test is claimed. Editorial policy · Affiliate disclosure