The Non-Custodial API Key Permissions Checklist
for Crypto Trading Bots

Every automated trading tool — ours included — asks you for an exchange API key at some point. The question that actually determines your risk isn't which tool you pick. It's which permissions you grant that key. Give it only what the job requires and a leaked key is an inconvenience. Give it more than that, and it's a different problem entirely.

There's a specific idea worth being precise about here: a non-custodial tool holds a key that lets it place orders on your behalf — it never takes custody of your funds. That distinction is real and it matters. But it only holds up as long as the key itself is scoped tightly. The moment a key also carries withdrawal permission, the line between “permission to trade for you” and “access to your assets” gets a lot blurrier — because whoever holds that key, leaked or not, can now move funds out directly.

Ten exchanges, checked against their own documentation

This table covers the four things that actually change your risk exposure: what permission categories an exchange lets you grant, whether trading and withdrawal can be separated, whether IP whitelisting is required or optional, and what happens to a key if you never touch either setting. Everything below is sourced from each exchange's own help center, developer docs, or announcements — where an official source couldn't confirm a detail, the cell says so instead of guessing.

Three differences worth slowing down for

Most of the table above is what you'd expect: read, trade, and withdraw as separate toggles, IP whitelisting as a risk-reducing option. Three exchanges break that pattern in ways that are easy to miss if you're used to how a different exchange works.

Gate.io: no trade-only option

Gate.io's own API documentation (updated 2026-07-06) is explicit: an API key is either Read and Write or Read Only. There is no middle setting. If a key can place orders, it can also initiate withdrawals — the permission model bundles both together with no way to grant one without the other.

To be precise about what this is and isn't: it's a description of how Gate.io's permission model is structured, not a statement about how safe Gate.io is as an exchange. Gate.io does layer its own withdrawal safeguards on top — withdrawals can only go to an address you've manually withdrawn to before, with a 24-hour cooldown after you add one. But at the API-key level, if you're connecting a Gate.io key to any trading tool, the usual “just uncheck withdrawal” advice doesn't apply — which makes the IP whitelist and the exchange's own withdrawal-address controls carry more of the weight.

Kraken: nothing expires unless you turn it on

Every other exchange in this table that documents an expiry rule forces it as a default — no IP whitelist means the key expires on a clock, whether you asked for that or not. Kraken doesn't work that way. Both “IP Address Restriction” and “Key Expiration” are settings you opt into yourself when creating the key. Leave them both off, and — per Kraken's own support documentation — the key simply doesn't expire.

If your mental model is “the exchange will expire my key for me eventually, so I don't need to think about it,” that model is wrong for Kraken specifically. Kraken puts the decision entirely in your hands, for better or worse.

Hyperliquid: a wallet signature, not a key

Hyperliquid is a perpetuals DEX, and it doesn't issue traditional API keys at all. Instead, your main wallet signs an ApproveAgent action that authorizes a separate API Wallet (Hyperliquid's docs also call this an Agent Wallet) to sign trading actions on your behalf. One account can have one unnamed API Wallet plus up to three named ones.

Here's the part that needs a careful hedge. Hyperliquid's documentation describes two distinct signature schemes: sign_l1_action for things like placing and canceling orders, and sign_user_signed_action for things like withdrawals and approving new agents. Based on that split, and on how Hyperliquid's own official SDK behaves, it appears that an Agent/API Wallet can only sign the first category — meaning it can't withdraw funds, only trade with them. That is our own technical reading of the design, not a sentence Hyperliquid's docs state outright anywhere we found. Treat it as a well-supported inference, not an official guarantee stated in plain language.

What's official policy, and what's just convention

A lot of “best practice” advice about API keys gets repeated so often it starts to sound like a rule every exchange enforces. Some of it is. Some of it isn't. Here's the honest split, so you know which parts are non-negotiable and which parts are you doing the exchange a favor it doesn't require.

The checklist

Three stages, each traceable back to something above rather than a generic “be careful” list.

Before you create the key

• Open your exchange's current API documentation directly — don't rely on a screenshot from an old tutorial. Permission menus and expiry defaults change; Gate.io's own page on this topic, for example, was last updated 2026-07-06.
• Confirm the tool you're connecting only asks for trading permission. If it also requests withdrawal, ask why — there's rarely a legitimate reason an automated bot needs to move funds out of your account.
• Check whether your exchange even lets you separate trading from withdrawal at the key level. Nine of the ten we checked do. Gate.io is the one exception — its Read and Write permission bundles both together, so plan your IP whitelist and withdrawal-address settings accordingly if that's your exchange.

While you're setting it up

• Leave withdrawal permission unchecked unless you have a specific, current reason to need it.
• Turn on IP whitelisting if the exchange offers it. On Binance, Bitget, KuCoin, and BingX it's not optional the moment withdrawal permission is involved. On the others it's optional but still worth doing — it's the one setting that works the same way on every centralized exchange here (a DEX like Hyperliquid has no IP-whitelisting concept at all). For a deeper, Binance-specific walkthrough of this step, see our guide to securing a Binance API key.
• If the exchange lets you set an explicit expiration date, consider doing it deliberately rather than depending on a default. Kraken specifically won't expire a key on its own unless you turn “Key Expiration” on yourself.

After it's live

• Note when your key is due to auto-expire if you skipped IP whitelisting — anywhere from 14 days (OKX, BingX) to 90 days (Bybit, Gate.io, MEXC) across the exchanges checked here. Bitget and KuCoin don't document any expiry at all, so a key there won't remind you on its own.
• Periodically re-check the permissions actually attached to the key inside your exchange account, not just what the tool's dashboard shows you. On an exchange like Gate.io, where permissions come bundled, it's easy for a key to carry more scope than you meant to grant.
• If your exchange and your tool both support it, consider running the bot out of a dedicated sub-account rather than your main balance. No exchange requires this, but several document it as their own recommendation for containing the damage if a key ever does leak.

What to ask before you connect a key to any tool

Whether it's us or someone else, three questions apply regardless of which tool you're evaluating:

• How is the key stored? Plaintext in a database is a red flag. Encrypted at rest, with the encryption key kept separately from the database itself, is the baseline worth asking about.
• Does it ever ask for withdrawal permission? If a tool that only places trades for you also wants withdrawal access, that's worth a direct question before you connect anything.
• Can it work with a trade-only key on your exchange? If your exchange supports the separation (nine of the ten above do), the tool shouldn't need more than that to function.

On our end: TVSBot encrypts stored API keys with Fernet (AES-128-CBC + HMAC-SHA256), with the master key held only in environment variables, separate from the database itself. Every order is placed directly against the exchange's own API using your key — TVSBot never takes custody of funds. Our own setup docs recommend an order-only key and publish a fixed IP you can whitelist on the exchanges that support it, since — as the table above shows — the whitelist is the one setting that consistently reduces risk across every centralized exchange here, whether or not that exchange makes it mandatory.

FAQ