Exchange APIs

6.1 Letting code place orders

Mint's system generated about one signal a month, at the daily close, which was midnight UTC. For Mint, that meant staying up late or waking up early to place orders.

"Can I just have a program do it?" Mint asked.

"You can," said Hash. "Most exchanges let programs place orders through an API. But giving software access to your exchange account is like giving someone a key to your house. You need to decide exactly which doors that key can open."

6.2 What an API is

An API (application programming interface) is a way for software to communicate with another system. Exchange APIs let programs do what you'd normally do in the exchange's app or website.

Common API functions	Example
Market data	Get prices, order books, candles, funding rates
Account data	Check balances, positions, and order history
Trading	Place, modify, and cancel orders
Transfers	Move funds between accounts, or withdraw (avoid enabling this, see below)

Two common API types:

Type	How it works	Typical use
REST API	The program sends a request and gets a response	Placing orders, checking balances
WebSocket API	A continuous connection streams live updates	Real-time prices and order updates

6.3 API keys

To use an exchange's API for your account, you create an API key, usually with two parts: a public key, which identifies you, and a secret key, which proves the request comes from you. The secret key works like a password and must be protected just as carefully (Module 2).

6.4 Permissions: the most important setting

Most exchanges let you choose what each API key is allowed to do.

Permission	Should you enable it for a trading bot?
Read account data	Yes, usually needed
Spot trading	Only if the bot trades spot
Futures and margin trading	Only if the bot trades derivatives, and carefully
Withdrawals	No. Almost never needed for trading, and the biggest risk if the key is stolen
Transfers between sub-accounts	Only if specifically required

"If someone steals a key without withdrawal permission," said Hash, "the worst they can usually do is make bad trades. With withdrawal permission, they can empty the account."

Even trade-only keys can be abused. Attackers have used stolen trading keys to make trades that move thinly traded prices to benefit their own accounts elsewhere. Limiting permissions reduces risk; it doesn't remove it.

6.5 More API security practices

Practice	Why
IP whitelisting	Restrict the key so it only works from your server's IP address
Separate sub-account	Run the bot in a sub-account holding only the capital it needs
One key per bot or service	If one is compromised, revoke it without affecting others
Never share keys or paste them into chats or websites	Phishing and malware target API keys (Module 2, Chapter 10)
Store keys securely	Use environment variables or secret managers, not code files shared publicly
Never commit keys to public code repositories	Automated scanners search public code for exposed keys within minutes
Rotate keys regularly	Limits the damage window if a key leaks
Revoke unused keys	Old keys are forgotten doors

Mint nearly made a classic mistake: putting the secret key directly in a code file and uploading it to a public repository to share with a friend. Hash stopped it just in time.

"Bots constantly scan public code for exchange keys," said Hash. "People have lost money within minutes of uploading one."

Chapter 6 · API key permissions

An API key can be scoped per permission: read enabled, spot or perp trading enabled, and withdrawals disabled, with an IP whitelist and a sub-account capital cap. A stolen trade-only key can disrupt positions but cannot move funds off the exchange, unlike a key with withdrawal rights.

6.6 Rate limits and reliability

Exchanges limit how many API requests you can make in a period, called rate limits. Exceeding them can get requests rejected or your key temporarily blocked, which might happen exactly when your bot needs to exit a position.

Example. Suppose an exchange allows 1,200 requests per minute. A bot that checks five markets once a second uses 5 × 60 = 300 requests a minute, well within the limit. The same bot checking thirty markets twice a second would use 30 × 120 = 3,600, three times over the limit, risking rejected orders just when it needs to act.

Other reliability issues include exchange outages during high volatility, connection drops, delayed data, and orders that are partially filled or rejected. A well-built system checks that orders were actually filled, handles errors, and alerts you when something unexpected happens (Chapter 10).

6.7 Using third-party bot platforms

Many people use third-party platforms that connect to exchanges through API keys and run strategies for them (Chapter 7). This adds a new risk: the platform itself.

Question	Why it matters
Is the platform reputable, with a long track record?	Platforms storing many users' keys are attractive targets
What permissions does it require?	Avoid any that require withdrawal permission
How does it store your keys?	Security practices vary
Can you restrict it to a sub-account?	Limits exposure

6.8 Try it yourself

On an exchange's testnet or demo environment, create an API key with read and trading permissions only, no withdrawals, and an IP restriction if available. Read the exchange's API documentation to find how to request your balance and the latest BTC price. Then check the API rate limits and note what happens if they're exceeded.

Key takeaways from this chapter

1. Exchange APIs let software access market data, account data, and trading functions.
2. API keys include a secret that must be protected like a password.
3. Never enable withdrawal permissions for trading bots, and limit other permissions to what's needed.
4. Use IP whitelisting, sub-accounts, separate keys per bot, secure storage, rotation, and revocation.
5. Never put API keys in public code; automated scanners find them quickly.
6. Plan for rate limits, outages, partial fills, and errors.
7. Third-party bot platforms add their own security risk; check reputation, permissions, and key storage.