What Is a Crypto Exchange API and Which Permissions to Enable

A crypto exchange API is a set of endpoints an exchange opens up to software. It does one thing: it replaces your finger with a line of code. Pull a candle, check a balance, place a limit order — actions that take four or five clicks in a web interface become a single HTTP request.

Most articles stop there. The part that actually burns people is the next question, and it rarely gets a straight answer: what can the key you just issued actually do, and what can it not do? Get the permission model wrong and you have handed a plaintext credential to a third-party script whose source you have never read.

This piece walks four lines — what it is, how to use it, how to call it, and whether it is safe. Concrete parameters come from the WEEX spot API documentation, last updated April 14, 2026. Other venues follow a similar shape with different numbers, so check your own exchange's current docs before you integrate.

What is a crypto exchange API? Public and private endpoints

A crypto exchange API is not one monolithic thing. It splits into two layers, and that split decides whether you need a key at all and how much risk you are carrying.

Public endpoints serve market data anyone can see: last traded price, 24-hour high and low, candles, order book depth, the full list of supported pairs. No authentication — a plain GET returns data. A price alert script or a backtest dataset needs nothing more, and never touches your account.

Private endpoints are the ones tied to your money: balances, order placement, cancellation, fill history, ledger records. Every request must carry a signature, and the server executes only after it validates.

The risk profiles are not comparable. The worst outcome on a public endpoint is that you get rate-limited. The worst outcome on a misconfigured private endpoint is that your positions move. Plenty of newcomers read "I want to use the exchange API" as "I need trading permission," when a large share of real use cases — portfolio dashboards, ledger sync, price alerts — are fully served by read-only access.

API Key, Secret Key and Passphrase: what each one does

Creating a key hands you three strings at once. They do different jobs, and people routinely store them together, paste the wrong one, and then cannot tell which link in the chain failed.

Two details are worth pulling out. WEEX requires the passphrase to be alphanumeric only — no special characters, a constraint that is not displayed prominently and is a common first-integration failure. And a forgotten passphrase cannot be recovered or changed; the documented fix is to delete the key and create a new one.

The practical move: the moment the key is created, write all three into a password manager or an environment file. Do not assume you can come back and copy them later.

Which crypto exchange API permissions should you enable?

This is the section worth remembering.

On WEEX, an account can create up to 10 API key groups, each configured independently. The documentation (April 14, 2026) lists exactly two permission types:

New keys default to read-only. Trading has to be enabled deliberately, and the two permissions are independent — without Spot checked, orders will not go through.

Note what is absent from that table: there is no withdrawal permission. That is a design boundary, not an oversight. The most destructive category of API incident — key leaks, funds transferred straight out — has no opening at the permission layer here. A stolen key is still dangerous; an attacker can wash-trade your balance away in an illiquid pair or bleed it out through junk fills. But the shortest path, draining the account, is closed.

To be clear: exchanges differ on this. Some venues do issue keys with withdrawal rights. Before creating a key anywhere, look at the permission checkboxes and see whether "Withdraw" is one of them. If it is, leave it off unless you are running cross-exchange automation and know exactly what you are doing.

One more parameter almost nobody mentions, and it will cost you half an hour: a newly created or modified API key typically takes about 15 minutes to propagate globally. Running a strategy immediately after creating the key and getting a permission error does not mean your code is wrong. It may just mean the key is not live yet.

The security guidance is equally direct: enable an IP whitelist. Once bound, even a full leak of all three credentials fails from any other address — the request is rejected outright. For a strategy running on a fixed server, this is the cheapest meaningful protection available. You can start from the WEEX API page.

How to call a crypto exchange API: signing and rate limits

Once permissions make sense, the rest is engineering. A complete private request looks roughly like this.

Step one, build the signing string. WEEX concatenates timestamp + uppercase method + requestPath + "?" + queryString + body, runs HMAC SHA256 with your secret key, then Base64-encodes the result. For a depth query, the string to be signed reads:

1591089508404GET/api/v3/market/depth?symbol=BTCUSDT&limit=20

When the query string is empty — most POST requests — the format collapses to timestamp + METHOD + requestPath + body.

Step two, set the headers. API key, signature, timestamp and passphrase go into their respective ACCESS headers. The timestamp is in milliseconds, and requests are rejected if it deviates more than 30 seconds from server time. That single number explains why the first endpoint in every exchange's docs is "get server time."

Step three, respect case and rate limits. The symbol parameter is case-sensitive and must be fully uppercase — btcusdt fails outright. On the throughput side:

Breaching any of these returns HTTP 429. Limits are calculated independently per endpoint, so a single global counter is the wrong way to throttle.

Two more traps: REST suits on-demand queries, but WebSocket is the right answer for live market data; and a WebSocket handshake must include a User-Agent header (contents are up to you) or the firewall blocks it with a 403 — an error that looks nothing like a missing header. Full worked examples sit on the official signature reference.

Error code triage: what each one actually means

Most API development time is not spent writing logic, it is spent reading errors. This table maps error to real cause to the action that fixes it.

Note: V1/V2 and V3 use different error-code schemes (4xxxx versus -10xx), so confirm which version you are calling before debugging. WEEX has stated V1/V2 are being deprecated — new integrations should target V3. Also worth knowing upfront: TradingView signal trading and FIX API are not currently supported, so any design depending on either needs a different path.

Is a crypto exchange API safe? Five places things break

"Is the exchange API safe" is too coarse a question. The protocol itself — HMAC signing, timestamp validation, IP checks — is mature. Almost every failure is a usage failure. Ranked by how often they actually happen:

1. Handing credentials to someone who should not have them. The top cause has never been a technical exploit; it is social engineering. Fake "managed quant" and "copy-trading accelerator" services ask you to paste an API key, and the balance is wash-traded into dust. The test is simple: any third party that asks for your secret key should be treated as hostile by default. Legitimate services have you bind the key on their platform; they do not ask you to paste it into a chat window.

2. Skipping the IP whitelist. As above, this is the single step that downgrades a leak from catastrophe to nuisance. The usual reason for skipping it is "my IP is dynamic," and the price is the entire perimeter.

3. Hardcoding keys and pushing to GitHub. Bots scanning public repositories for credentials run around the clock; the window between commit and exploitation is often measured in minutes. Use environment variables and put the config file in .gitignore.

4. Granting far more permission than the job needs. A portfolio dashboard with Spot permission enabled is carrying risk for a capability it never invokes. One purpose, one key, minimum permission — 10 key groups is plenty of headroom to segment properly.

5. Writing optimistic error handling. This one does not involve a leak, but it costs real money. Strategies that do not retry after a 429, that keep firing orders after a disconnect without reconciling positions, that treat a failed cancel as a successful one — these defects surface together during violent moves, which is precisely when you least want the program improvising. The official docs put "ensure your code includes robust error-handling logic" in the developer notes for a reason.

The more useful framing is this: the risk structure of a crypto exchange API is nothing like holding spot. Spot losses come from the market. API losses usually come from you — one unchecked return value, one unthrottled loop, and a position can be shredded while you sleep. Which is why experienced operators run a read-only key for a week first, confirm the data flow, the error paths and the alerting all behave, and only then enable trading.

Three things to remember before your first key

Back to the original question. A crypto exchange API is the interface an exchange opens to software, turning manual clicks into executed code so market data and trading can be automated.

What actually determines whether it goes smoothly comes down to three things:

1. Minimum permission. If read-only solves the problem, do not enable trading. One purpose, one key.
2. The IP whitelist is the highest-return step you can take. When credentials leak, it is the only defense still standing.
3. Run read-only first, trade second. Validate data, errors and alerts before granting permission — far cheaper than the post-mortem.

If you want to start, the WEEX API preparation guide covers key creation and permission setup end to end, and the API FAQ page collects the rate-limit rules and the errors people hit most. Create a read-only key first and run the market data endpoints through your full pipeline before anything else.

FAQ

1. What is a crypto exchange API in one sentence?

It is the interface an exchange exposes to software, letting code fetch market data, check balances, and place or cancel orders — the technical foundation for quant trading, copy-trading bots and automated monitoring.

2. Do I need to know how to code to use an exchange API?

Calling endpoints directly requires basic programming skill, most commonly Python. Many third-party tools wrap that logic so you only bind an API key on their platform — provided the tool is trustworthy and never asks you to paste your secret key into a chat window.

3. If my API key leaks, can someone withdraw my coins?

It depends on whether the platform offers withdrawal permission. The WEEX spot API documentation (April 14, 2026) lists only Readonly and Spot, with no withdrawal option, so a leak cannot move assets off the exchange directly — though an attacker could still cause losses through malicious orders. Other exchanges design permissions differently, so verify yours. Delete any key you believe is compromised immediately.

4. What if I forget the passphrase?

It cannot be recovered or modified. The only fix is deleting the API key and creating a new one. WEEX also requires the passphrase to be alphanumeric, with no special characters.

5. My new API key returns a permission error — did I configure it wrong?

Not necessarily. Newly created or modified keys usually take around 15 minutes to propagate globally, so retry after waiting. If it persists, check that the trading permission is enabled and that the pair supports API orders.

6. Should I use REST or WebSocket?

REST for on-demand calls — balances, placing and cancelling orders. WebSocket for live data — tick-level fills and depth updates. Production strategies typically run both: WebSocket in, REST out.

7. Can I run arbitrage or high-frequency strategies through an exchange API?

Technically yes, but rate limits bind. On WEEX spot that means 100 orders per 10 seconds and 500 IP weight per 10 seconds, with each endpoint counted independently. Genuine high-frequency work also has to price in latency, slippage and fee structure, which regularly consume the spread that looked available on paper.

Risk Warning

Crypto asset prices are highly volatile and may result in partial or total loss of capital. Trading programmatically through a crypto exchange API layers additional risk on top of market risk: a flawed strategy can compound losses unattended; network interruptions, rate-limit rejections or unexpected responses can leave order state out of sync with actual positions; and API credentials leaked through phishing, exposed code or untrusted third parties can enable losses through malicious orders even where withdrawal is not permitted. Futures and leveraged trading add liquidation risk, where a short-lived price move can wipe out the full position. Test strategies thoroughly, enable IP whitelisting and minimum permissions, and commit only capital you can afford to lose. This article is informational and does not constitute investment advice.