29 September 2026 · 3 min read

Building an exchange API traders will actually use

REST for orders, websockets for fills, keys with permissions and rate limits that protect you. What professional users check before they move volume to your venue.

The traders worth having do not click. They connect. Whether your venue gets their volume is decided by an API they will evaluate in about twenty minutes, mostly by looking for the things that have burned them elsewhere.

What has to exist

REST for actions. Place, cancel, query orders. Balances. Deposit addresses. Withdrawal requests, if you allow them by API at all.

Websockets for everything live. Order book updates, trades, and a private stream for the user's own fills and balance changes. Polling an order status every second is how a trader gets rate limited and how you get load you did not need.

Keys with permissions. Read only, trade, and withdraw as separate scopes, with IP allow lists. A key that can only read must never be able to move money, and most traders will create one of each before trusting you.

Rate limits that are documented and honest. Per endpoint, with the remaining allowance returned in a header. A limit nobody can see is a limit everybody hits.

The details professionals check first

• Client order IDs. Can they set their own ID so a retried request cannot place a second order? If not, they cannot build anything safe.
• Error shapes. One consistent format with a machine readable code. Not a 200 with the word "error" in the body.
• Decimals. Numbers as strings, with precision per pair stated. Floats in a financial API are a red flag on their own.
• Snapshot plus deltas. A book feed that gives a snapshot with a sequence number, then increments, so a client can detect a gap and resynchronise.
• Timestamps in milliseconds, in UTC, consistently, everywhere.

A trader's first question is not "how fast is it". It is "what happens when my request times out and I do not know whether the order was placed".

Rate limits protect you, not them

Without limits one badly written bot can take your venue down for everyone. With limits, that bot gets throttled and everybody else keeps trading. Weight the expensive endpoints higher, keep cancels cheap, since a trader who cannot cancel in a fast market will leave and tell people why.

Documentation is part of the product

A page per endpoint with a working example, the error codes, the limits and a changelog. Most exchange documentation is a schema dump, which is why integrating with a new venue is so unpleasant and why good documentation is a genuine advantage for a small venue.

If you are also shipping an app, the same API serves it, as noted in the mobile app guide.

Questions

What does a crypto exchange API need

REST for orders and account actions, websockets for live book, trade and private fill data, API keys with separate read, trade and withdraw permissions, documented rate limits, and consistent error codes.

Why do traders want client order IDs

So a retried request after a timeout cannot create a duplicate order. Without them, every network hiccup risks double trading, and no serious bot will connect.

Should API keys be allowed to withdraw

Only as a separate permission, off by default, ideally with an IP allow list. Most users want a trade only key, and giving them that is a security feature you can advertise.

What rate limits are reasonable

Whatever you can document and return in a header. Weight heavy endpoints more and keep cancellations cheap, because a trader who cannot cancel during volatility will leave permanently.

Do numbers need to be strings in an API

Yes. Floating point rounding in a financial API causes mismatches between your records and the client's, and professional users treat floats as a sign the venue has not thought it through.

Is the API included in a standard build

A working REST and websocket layer is part of the exchange build. Public documentation, published limits and versioning are a step beyond that and get scoped when you want the venue to attract bots.