Checklist

Exchange API integration checklist

A practical checklist for building or reviewing an exchange API integration: permissions, signing, clock sync, rate limits, client order IDs, retries, partial fills, reconciliation, restart behavior, logging and go-live. Every section ends with a test you can run.

Documentation examples read on November 5, 2026

How to use it. Work through it with your developer, or use it to check work you received. An item is done when someone can point to the code and a test, not when someone says it is handled. Fincode sells this kind of work, so this page is not neutral on whether you should hire someone.

The examples come from each platform's public documentation, read on November 5, 2026, and they can change. Exchanges are named only to illustrate published APIs. That is not a recommendation, and it does not mean Fincode has integrated them or will. There are no referral links. Which platforms you can use depends on the law of your country and the platform's terms. Article 99/A of Capital Markets Law No. 6362 treats activity by foreign crypto-asset platforms directed at Turkish residents as unauthorized.

1. Before you start: terms and environments

Check what you are allowed to build, and where you can test it, before anyone writes code.

You have read the platform's API terms for your exact use. Your own account, a commercial product and trading for third parties can be treated differently.
You have checked that the platform can be used from your country, and by whoever else the software serves.
The API version and endpoints the project depends on are listed, and someone is named to watch the changelog.
You know whether a testnet or sandbox exists, and what it does not reproduce.

Test it. Point to the clause that allows your use, with the date you read it. Then send one signed request to the test environment, before anything else is built.

Documented example. OKX TR's API agreement (opens in a new tab), section 9.3, bars offering its API services inside a commercial product, SaaS or managed trading service, and operating accounts for third parties, without written authorization. The same section says that trading on your own account through the API is not commercial sale. The Turkish connectors page lists two more platforms whose terms restrict automated use.

2. Permissions and keys

Give the key the least it needs, so that a leak costs as little as possible.

Each bot or service has its own key, so revoking one stops one thing.
The key has read permission only if the software only reads, and read and trade if it trades. Withdrawal permission is off.
IP restriction is on and set to the server's address, where the platform supports it.
Asymmetric keys are used where offered, so the private key never leaves your server.
Keys stay out of code, repositories, tickets, chat and incoming messages, and are encrypted where they are stored.
Rotation and revocation are written down, and have been done at least once.
Test and live keys cannot be mixed up. The software states its environment at start-up.

Test it. On a test environment, revoke the key while the software runs: it should stop safely and alert. Call an endpoint the key should not reach: the call should be refused. Run a secret scanner over the repository and its full history.

Documented examples. Binance (opens in a new tab) limits system-generated HMAC keys without an IP restriction to read permission. Coinbase (opens in a new tab) recommends an IP allowlist for its App API keys, and its key setup includes portfolio and permission restrictions. OWASP (opens in a new tab) calls for immediate revocation of exposed keys. See also API key security for trading bots.

3. Signing

A signature fails when the bytes you signed differ from the bytes you sent, and the error rarely says why.

The signer has been tested against the platform's own worked example, if it publishes one, before any live call.
The request is serialized once, and that exact string is signed and sent: same parameter order, encoding and body.
Timestamp, nonce or token is created at the last moment before sending, after any queue.
Signing and permission errors stop and alert. They are not retried unchanged.
Secrets and finished signatures never reach a log, including at debug level.

Test it. On a test environment, change one byte of a signed request. It should be rejected, and the software should log the reason and not loop.

Documented examples. Binance (opens in a new tab) supports HMAC, RSA and Ed25519 keys for signed endpoints. Coinbase's App APIs (opens in a new tab) need a different JSON Web Token for each request, valid for two minutes and signed with ES256.

4. Clock sync

Signed requests depend on time or on an ever-rising number, so a wandering clock can look like an authentication failure.

The host keeps its clock in sync, and something alerts if that sync fails.
The offset against the exchange's server time is measured at start-up and periodically, and it is logged.
Past a threshold you set, new orders are blocked and someone is told.
The request time window stays small. Nobody has widened it to make timestamp errors go away.
On nonce-based APIs, one key serves one process, and the nonce never goes backward, including after a restart or clock correction.

Test it. Move a test host's clock past the window during a run. Requests should be rejected, new orders should stop, an alert should go out, and the software should recover after the correction.

Documented examples. Binance (opens in a new tab) rejects a signed request whose timestamp is a second or more ahead of server time or older than recvWindow, which defaults to 5,000 ms, cannot exceed 60,000 ms and is recommended at 5,000 ms or less. Kraken (opens in a new tab) needs an always-increasing nonce per key, names shared keys and clock drift as causes of out-of-order nonces, warns that repeated invalid nonces can bring temporary bans, and offers no way to reset a nonce lower.

5. Rate limits

Limits are measured differently on each platform, and the penalty for ignoring them can land on your order path.

Every limit that applies is listed with its scope: per IP, per key, per account, per endpoint, order rate and connections.
A client-side budget stays below each limit, and every process that shares the IP or key shares the budget.
Order traffic takes priority over reads. Market data comes from streams where the platform offers them, not from polling.
A rate-limit response is honored: no request goes out before the wait the exchange states.
Usage counters are logged, and someone is told before a limit is reached.
Bursts from restarts, reconnects and reconciliation are counted in the budget.
Nobody spreads traffic over extra keys, accounts or IP addresses to get around a limit. If you need more, ask the platform.

Test it. Have a proxy return a rate-limit response several times in a row. Nothing should be sent during the wait, and orders should recover after it.

Documented examples. Binance (opens in a new tab) bases request limits on IP and not on the key, answers a breach with HTTP 429 and a Retry-After header, and bans IP addresses that keep sending with HTTP 418, for 2 minutes up to 3 days. Kraken (opens in a new tab) gives each key a call counter whose ceiling and decay depend on the account's verification tier, with order placement and cancellation on a separate limiter. See also the Binance API rate limit guide.

6. Symbol rules and precision

An order can be well signed and still rejected, or be the wrong size, because of how a number was rounded.

Prices and quantities use decimal types, not binary floats, in anything that reaches an order.
Tick size, step size, minimum and maximum quantity and minimum order value are read from the API, not hard-coded, and they are refreshed.
Rounding direction is a decision, written down. Quantity never rounds up past a balance or a risk limit.
An order below the minimum is not sent, and the reason is logged.
Symbols are mapped explicitly. An asset quoted in a stablecoin is not silently treated as quoted in US dollars.

Test it. Against a fake exchange, change a symbol's step size and minimum order value. Orders should adapt or stop, and a rejected order should not be retried unchanged.

Documented example. Binance's filters (opens in a new tab) need a price divisible by the tick size and a quantity divisible by the step size, set a separate lot size rule for market orders, and bound the order value.

7. Client order IDs

A client order ID is what lets you find an order after you lost the response, but on some platforms it does not stop duplicates on its own.

The ID is created before the first send and stored with the order intent, before the network call.
The ID comes from your own decision ID, so a retry of the same decision cannot produce a new one.
Your own ID never repeats across your records, and it is stored beside the exchange's order ID.
The format fits the platform's length and character rules.
How the platform treats a repeated ID is written down, because the rules differ.

Documented client order ID rules, read November 5, 2026 (alphabetical)
Exchange API	Field	Documented rule
Binance Spot (opens in a new tab)	`newClientOrderId`	Unique among open orders. The same ID can be accepted again once the earlier order has filled
Coinbase Advanced Trade (opens in a new tab)	`client_order_id`	Required. If it is not unique, no new order is created and the existing order comes back
Kraken Spot (opens in a new tab)	`cl_ord_id`	A UUID or up to 18 characters of text, checked against the client's open orders

Test it. On a test environment, send the same ID twice: once while the first order is open, and once after it has filled. Record what happens, and make sure your retry logic matches. On Binance Spot, for example, a blind resend after a fill can place a second order.

8. Retries and reconnects

A timeout on an order does not tell you the order failed. It tells you that you do not know.

Each call is classified: reads can be retried, while anything that creates or changes an order follows the rules below.
A timeout or 5xx on an order is recorded as an unknown outcome, never as a failure.
The order is looked up by client order ID before anything is resent. A resend happens only after the platform confirms the order does not exist.
A 4xx rejection is not retried unchanged. Something has to change first.
Backoff is exponential with jitter, capped, with a maximum number of attempts, and then it stops and alerts.
Retries live in one layer, so nested retries do not multiply each other.
WebSocket reconnects use backoff, subscribe again, and detect silent connections with a heartbeat deadline.
After a reconnect, state is rebuilt and reconciled before any new order.

Test it. Put a proxy between the software and a test environment. Let it forward an order and replace the response with HTTP 503: you should end up with one order. Cut the event stream with an order open and let the order fill during the gap: the fill should still be recorded.

Documented examples. Binance (opens in a new tab) says the execution status after an HTTP 5XX is unknown and could have been a success. Kraken (opens in a new tab) warns that connections can go silent without a clean close, and it does not restore subscriptions after a reconnect. AWS's article on retries (opens in a new tab) explains why calls with side effects are not safe to retry without idempotency, and why jitter matters.

9. Partial fills

Positions should follow what the exchange says filled, not what you asked for.

Position changes only on fills the exchange reports, never on the requested quantity.
The cumulative filled quantity is used where the platform provides it.
Applying the same event twice has no effect, because execution IDs are stored.
A late event cannot move an order backward. An illegal state change stops that order and triggers reconciliation.
A cancel that races a fill ends with the correct record: canceled, with the part that filled.
Fees taken in the traded asset are counted, so the position matches the balance.
What happens to the unfilled rest of an order at its time limit is specified.

Test it. Make an order fill in parts, deliver one event twice and cancel at the same moment as a fill, on a test environment or a simulator. Compare your position with the exchange's balance after each step.

Documented example. Binance's executionReport (opens in a new tab) carries the last executed quantity (l), the cumulative filled quantity (z), the order status (X) and an execution ID (I). See also what an order management system does.

10. Reconciliation

Your records and the exchange's will drift apart eventually, so the software should look for it.

Open orders, fills and balances or positions are compared with the platform's records.
This runs at start-up, after every reconnect and on a schedule.
Its request cost is budgeted, so it cannot use up the limit that orders need.
A difference with no explanation blocks new orders and alerts someone.
A named person releases the block, and the release is logged.
You have decided what happens if someone trades by hand on the same account.
Clean runs are logged too, so you can tell that it ran.

Test it. Place an order by hand on the test account, and delete a fill from the local records. Both should be found, new orders should stop and an alert should go out.

Documented example. Kraken (opens in a new tab) advises checking open orders from its WebSocket snapshot against a REST query after a reconnect.

11. Restart behavior

Software that wakes up remembering nothing can open a second position beside one it forgot.

Order intents, client order IDs and applied events are stored durably, and intents are written before sending.
On start-up, no new orders are accepted until recovery has finished.
Each unfinished order is resolved by a query. Nothing is resent on an assumption.
Reconciliation passes before new orders open.
Decisions that went stale during the outage are not replayed. The age limit is one you set.
An emergency stop survives a restart.
A crash loop stops and alerts, and does not keep restarting into the same failure.
You have considered the platform's dead man's switch, if it has one, for orders left open while the software is down.

Test it. Kill the process without warning, not with a clean stop, at three points: after the intent is saved and before the send, after the request leaves and before the response, and after a fill and before the event is applied. Each time, check for duplicates and compare state with the exchange.

Documented example. Kraken (opens in a new tab) describes CancelAllOrdersAfter as a dead man's switch that cancels open orders if the client stops refreshing it.

12. Logging and alerts

After an incident, the logs are the only witness. They should be able to answer why an order went out.

Every decision, check result, order request, response, state change and manual action is logged in UTC, with one ID carried from decision to order to fill.
API keys, signatures and tokens are masked, and a test proves it.
Logs survive the process and the host. The retention period is written down.
Clocks are in sync on every host that writes logs.
Alerts cover blocks, freezes, unresolved outcomes, failed reconnects, clock offset and restarts.
Something outside the process notices when the process is dead.
A named person receives the alerts, and delivery has been tested.

Test it. Pick a random order from a test run and explain it from the logs alone. Search all logs for the key, the secret and signature values: there should be no matches.

Documented example. OWASP's logging guidance (opens in a new tab) says access tokens, passwords and encryption keys should usually not be recorded directly, and it recommends synchronizing time across servers.

13. Go-live

Go-live is the point where a bug starts to cost real money, so make it small and reversible.

Tests ran in order: historical data, then a testnet with failure cases, then a paper trading account with live market data.
A person on your side has read and approved the test report.
The live configuration has been reviewed line by line: URL, key, instruments and limits.
Risk limits run outside the trading rules, with values you set, and the emergency stop has been tried on the live configuration.
The account holder created the live key, and its permissions and IP restriction have been checked.
Go-live starts with small limits, and the first live orders are compared with the exchange's records by hand.
A runbook covers start, stop, restart, key rotation and releasing a freeze, and says who does each one.
Someone owns the platform's API changelog from this day on.

Test it. Before the first live order, have the people who will run the software rehearse the runbook on the test environment: stop, restart, rotate a key and release a freeze.

Documented example. The Binance Spot Test Network (opens in a new tab) uses virtual funds and resets about once a month without prior notice. Its filters and limits are generally the same as live, but only /api endpoints are available. So a test environment can prove your error handling, not live behavior.

Passing this checklist shows how the software behaves. It says nothing about whether your rules will make money, and trades can lose money.

Sources

All opened on November 5, 2026.

This checklist is general information about software, not investment, legal or tax advice. Automated trading can lose money, and the rules that apply depend on your jurisdiction and your exchange's terms. Fincode is a software company and does not provide investment advice, portfolio management or crypto asset services.

In practice

Where these items end up

In a project, this checklist turns into written requirements, acceptance checks and a test report. The samples show that format, with a fictional project for the scope document and a run of Fincode's published reference code for the test report, so you can compare it with what you receive from anyone.

If you want this work done, send a short brief. The four stages explain what you approve and receive at each step, and the exchange API integration service describes the scope.

Samples

FAQ

Questions about exchange API integration

What should an exchange API integration checklist cover?

API terms and test environments, key permissions, request signing, clock sync, rate limits, symbol rules, client order IDs, retries and reconnects, partial fills, reconciliation, restart behavior, logging and go-live. Give the failure paths the most attention, because the normal path is the easy part.

Can I simply retry an order after a timeout?

No. A timeout means the outcome is unknown, and the order may have gone through. Look it up by client order ID first, and resend only after the platform confirms it does not exist.

Do client order IDs prevent duplicate orders?

Not reliably. Rules differ by platform: an ID may be checked only against open orders, so the same ID can be accepted again later. Use the ID to look up the order before any resend.

Does a clean testnet run mean the integration is ready?

No. A testnet shows how your code handles the API, but its balances are virtual and it may not reflect live liquidity. Failure cases, a paper trading period and a go-live with small limits still follow.

Has Fincode integrated the exchanges named on this page?

Naming an exchange here only illustrates its public documentation. It is not a statement that Fincode has integrated it or will. Fincode has no client references to show.

Does passing this checklist mean the software will make money?

No. The checklist covers how the software behaves. It says nothing about whether your rules will make money, and trades can lose money.

Need an integration built or checked?

Tell us the platform you use, what the software should do and your timeline. For customers outside Türkiye, which platforms can be used depends on the law of your country and the platform's terms. For customers resident in Türkiye, we work with platforms on the Capital Markets Board's list that offer an API; being listed does not mean a platform is authorized. Fincode is a software company and does not provide investment advice, portfolio management or crypto asset services.

Send a project brief