Learn / Exchange APIs

Choosing an exchange for automation

Figures on this page are as of 2026-09. Fees, limits and margin tiers change — check the venue's own docs before acting on a number.

Fees and listings dominate exchange comparisons. For automation, the properties that decide how much work you are signing up for are the permission model, the testnet arrangement, and the error design — none of which appear in marketing material.

The checklist that matters

1. Can the credential be scoped?

The most important property, because it is the boundary enforced by someone other than your own software.

VenueMechanism
BinancePermission flags; withdrawals require IP restriction; spot trading expires at 90 days without an IP whitelist
BybitScopes on the key; IP binding enforced (10010)
AlpacaAccess Controls: Read only / Full access / Custom per scope
IBKRApplication-level Read-Only API — on by default
HyperliquidNo key; agent-wallet delegation

Alpaca’s per-scope Custom option is the most granular. IBKR’s is the only default-safe one. See read-only vs trade permission.

2. How is testnet separated?

This determines how an environment mistake fails.

  • Separate hostname — Binance, Bybit, Hyperliquid, Alpaca. A mix-up produces an authentication error rather than a live order. Prefer this.
  • Header switch — OKX uses the same host with x-simulated-trading: 1. A dropped header means production.

See practising on testnet before going live.

3. Does authentication require signing?

ApproachVenuesConsequence
Bearer credentialsAlpacaNo signature bugs. An entire class of problem does not exist
HMAC signatureBinance, Bybit, OKXPre-hash construction differs per venue; clock skew becomes an auth failure
Wallet signingHyperliquidDifferent model entirely
Socket to desktop appIBKR TWSNo credential; the app must be running

The three signing venues each construct the pre-hash string differently, so code does not port — see Bybit API key setup.

4. Are errors specific?

Debugging time is roughly inversely proportional to error specificity.

Good: Bybit separates permission (10005) from IP mismatch (10010) from rate limit, and splits account-level (10006) from IP-level (10018).

Less good: Binance -2015 covers bad key, wrong IP and missing permission in one code — see Binance API error -2015.

Worth checking: whether the venue publishes a complete error list at all. We could not retrieve OKX’s, which is why our 50113 article carries a provenance caveat.

5. Is state queryable?

Can you ask the venue what your key is permitted to do? Binance exposes GET /sapi/v1/account/apiRestrictions, which lets a process assert its own permissions at startup. Not every venue offers an equivalent, and without one you are relying on memory.

6. What does the rate limit meter?

  • Binance — request weight, not count. Endpoints cost differently, and 429 escalates to a 418 IP ban.
  • Bybit — account-level and IP-level limits, reported separately.
  • Hyperliquid — an address-based allowance earned by trading volume, on top of the IP limit. A new account has a small budget regardless.
  • IBKR Client Portal — 10 requests/second per username.

Hyperliquid’s model is the one that surprises people, and it is worth knowing before you build.

7. Sub-accounts?

A funded boundary is the only control that bounds damage from software working as designed but wrong — see using sub-accounts for automation.

8. Is there an official MCP server?

Alpaca (alpacahq/alpaca-mcp-server), OKX (okx/agent-trade-kit) and IBKR (a hosted connector) publish their own. For others what exists is community code, which is a different trust decision — exchange and broker MCP servers compared.

The structural constraints

Two that no amount of engineering removes:

IBKR requires a logged-in application. The TWS API is a socket to running software; the Client Portal Web API needs daily re-authentication IBKR does not support automating. Unattended automation inherits a recurring human step.

Hyperliquid has no API keys. All key-permission advice needs translating to the agent-wallet model — see Hyperliquid API setup.

What barely matters

Fee tiers, unless you are high-turnover. The trading fee calculator shows when it matters, and for most people it is below the noise.

Listing count. You will trade a handful of instruments.

Advertised uptime. What matters is how it degrades — partial degradation is more dangerous than a clean outage.

FAQ

What should I look for in an exchange API for automation?

Whether credentials can be scoped to read-only, whether testnet is a separate hostname, whether errors distinguish between causes, and whether you can query what a key is permitted to do. These determine how much work the integration is and how safely it fails — fee tiers and listing counts rarely do.

Which exchange is easiest to automate?

Alpaca, largely because it uses bearer credentials rather than request signing, which removes signature construction, clock skew and pre-hash bugs entirely. It also has per-scope key permissions and paper trading on a separate hostname with an identical API.

Why does testnet separation matter for choosing an exchange?

Because it decides how an environment mistake fails. With a separate hostname, testnet credentials do not exist in production, so pointing at the wrong one produces an authentication error. With a header switch, forgetting the header means you are in production with live credentials.

Should I choose an exchange based on whether it has an official MCP server?

It is a reasonable input rather than a deciding factor. An official server means the venue has some stake in it handling your credentials correctly, which is a different trust decision from installing community code. It matters less than whether the key can be scoped read-only, which protects you regardless.