# Exchange API integration checklist

URL: https://fincodelabs.com/en/exchange-api-integration-checklist · Publisher: Fincode (Fincode Yazılım ve Teknoloji A.Ş.), Istanbul, Turkey · Updated: 2026-11-06

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](https://web3.okx.com/tr/help/okx-api-agreement), 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](https://fincodelabs.com/en/services/turkish-exchange-connectors) 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](https://www.binance.com/en/support/faq/how-to-create-api-keys-on-binance-360002502072) limits system-generated HMAC keys without an IP restriction to read permission. [Coinbase](https://docs.cdp.coinbase.com/coinbase-app/authentication-authorization/api-key-authentication) recommends an IP allowlist for its App API keys, and its key setup includes portfolio and permission restrictions. [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) calls for immediate revocation of exposed keys. See also [API key security for trading bots](https://fincodelabs.com/en/blog/api-key-security-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](https://github.com/binance/binance-spot-api-docs/blob/master/rest-api.md) supports HMAC, RSA and Ed25519 keys for signed endpoints. [Coinbase's App APIs](https://docs.cdp.coinbase.com/coinbase-app/authentication-authorization/api-key-authentication) 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](https://github.com/binance/binance-spot-api-docs/blob/master/rest-api.md) 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](https://docs.kraken.com/exchange/guides/rest/authentication) 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](https://github.com/binance/binance-spot-api-docs/blob/master/rest-api.md) 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](https://docs.kraken.com/exchange/guides/rest/ratelimits) 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](https://fincodelabs.com/en/blog/binance-api-rate-limit).

## 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](https://github.com/binance/binance-spot-api-docs/blob/master/filters.md) 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](https://github.com/binance/binance-spot-api-docs/blob/master/rest-api.md) | `newClientOrderId` | Unique among open orders. The same ID can be accepted again once the earlier order has filled |
| [Coinbase Advanced Trade](https://docs.cdp.coinbase.com/api-reference/advanced-trade-api/rest-api/orders/create-order) | `client_order_id` | Required. If it is not unique, no new order is created and the existing order comes back |
| [Kraken Spot](https://docs.kraken.com/exchange/guides/general/clordid) | `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](https://github.com/binance/binance-spot-api-docs/blob/master/rest-api.md) says the execution status after an HTTP 5XX is unknown and could have been a success. [Kraken](https://docs.kraken.com/exchange/guides/websockets/reconnection) warns that connections can go silent without a clean close, and it does not restore subscriptions after a reconnect. [AWS's article on retries](https://builder.aws.com/content/3EumjoZascWd1oZiEgL8ORlv3qE/timeouts-retries-and-backoff-with-jitter) 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`](https://github.com/binance/binance-spot-api-docs/blob/master/user-data-stream.md) 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](https://fincodelabs.com/en/blog/crypto-order-management-system).

## 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](https://docs.kraken.com/exchange/guides/websockets/reconnection) 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](https://docs.kraken.com/exchange/guides/websockets/reconnection) 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](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) 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](https://testnet.binance.vision/) 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.

- [Binance Spot API documentation: REST API (signing, timestamps, limits, 5XX handling, order parameters)](https://github.com/binance/binance-spot-api-docs/blob/master/rest-api.md)
- [Binance Spot API documentation: User Data Streams (executionReport)](https://github.com/binance/binance-spot-api-docs/blob/master/user-data-stream.md)
- [Binance Spot API documentation: Filters](https://github.com/binance/binance-spot-api-docs/blob/master/filters.md)
- [Binance: How to create API keys (permissions and IP restriction)](https://www.binance.com/en/support/faq/how-to-create-api-keys-on-binance-360002502072)
- [Binance Spot Test Network](https://testnet.binance.vision/)
- [Coinbase: API key authentication](https://docs.cdp.coinbase.com/coinbase-app/authentication-authorization/api-key-authentication)
- [Coinbase Advanced Trade API: Create Order](https://docs.cdp.coinbase.com/api-reference/advanced-trade-api/rest-api/orders/create-order)
- [Kraken: Spot REST authentication (nonce)](https://docs.kraken.com/exchange/guides/rest/authentication)
- [Kraken: Spot REST rate limits](https://docs.kraken.com/exchange/guides/rest/ratelimits)
- [Kraken: Client order identifiers (cl_ord_id)](https://docs.kraken.com/exchange/guides/general/clordid)
- [Kraken: WebSocket reconnection and resilience](https://docs.kraken.com/exchange/guides/websockets/reconnection)
- [OKX TR: API agreement (Turkish), section 9.3](https://web3.okx.com/tr/help/okx-api-agreement)
- [OWASP: Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html)
- [OWASP: Logging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html)
- [AWS: Timeouts, retries and backoff with jitter](https://builder.aws.com/content/3EumjoZascWd1oZiEgL8ORlv3qE/timeouts-retries-and-backoff-with-jitter)
- [Capital Markets Law No. 6362, Article 99/A (Turkish)](https://www.mevzuat.gov.tr/mevzuatmetin/1.5.6362.pdf)

> 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.

## 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](https://fincodelabs.com/en/contact). The [four stages](https://fincodelabs.com/en/how-we-work) explain what you approve and receive at each step, and the [exchange API integration service](https://fincodelabs.com/en/services/exchange-api-integration) describes the scope.

### Samples

- [Sample scope document](https://fincodelabs.com/en/samples/scope-document)
- [Sample test report](https://fincodelabs.com/en/samples/test-report)
- [Sample code review report](https://fincodelabs.com/en/samples/code-review-report)
- [All samples](https://fincodelabs.com/en/samples)

## 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.

---

Published by Fincode (Fincode Yazılım ve Teknoloji A.Ş.), a software company in Istanbul, Turkey: https://fincodelabs.com/en/exchange-api-integration-checklist