Bitget API Key Security: The Complete Guide
sub-account isolation, IP whitelist, Passphrase — the three that matter

The moment you wire up a TradingView signal or a trading bot to Bitget for auto-order execution, the very first thing you do is create an API key — and that’s where Bitget API key security is actually decided. 90% of people grant too many permissions at this step — they follow a Binance tutorial they found online, tick boxes on autopilot, and completely miss that Bitget adds a Passphrase, has no standalone “Read” checkbox, and — crucially — offers a whole mechanism where sub-accounts can manage their own API keys that almost nobody turns on. This guide takes Bitget’s official API docs plus the parts we already verified in our cross-exchange API key permissions checklist and distills them into a Bitget-specific playbook. Three things only, all chosen because they actually move the needle on how much risk your key carries: least-privilege permissions, IP whitelisting, and the sub-account isolation nobody enables.

This isn’t a comparison of whether Bitget is more secure than the other exchanges — that would need cross-exchange live testing and an audit of internal controls; we haven’t done that, and this article isn’t going to pretend to. It also isn’t about running trading strategies on Bitget; the scope is strictly the API key layer. That scope is deliberate: get this one layer right and even if some downstream tool gets breached later, your funds can’t be moved; get it wrong, and every other safeguard downstream is just decoration.

Bitget’s API Key Permission Model: Two APIs, Two Interfaces

Bitget currently runs two APIs side by side: the Classic API (the older interface with separate spot and futures endpoints) and UTA (Unified Trading Account) — the newer interface that Bitget’s own docs mark as “🔥 Recommended”. The permission model differs slightly between the two, and the actual checkboxes the UI shows you shift depending on which account mode you’re in. This is different from Binance and BingX, which each have a single fixed permission list, and it’s a piece of complexity that’s specific to Bitget.

There’s another place Bitget diverges from Binance and BingX — Bitget’s API auth requires three keys, not two: ACCESS-KEY, Secret Key, plus a Passphrase. The Passphrase is a password you set yourself at the moment you create the key, and the docs are blunt about it: “if the Passphrase is forgotten, it cannot be retrieved and the APIKey needs to be re-created” — forget it and you rebuild the key. This design mirrors OKX and stands apart from Binance and BingX, which only issue API Key + Secret. The practical consequence: a leak of any one of your three keys can cause loss of funds — Bitget’s official risk notice puts it as “The leakage of any one of these three keys may cause the loss of your assets” — so the Passphrase deserves the same secret treatment as the API Key and Secret, and belongs in the same password manager alongside them.

Three Must-Do Settings: Disable Withdraw, Bind IPs, Use a Sub-Account

Setting 1: don’t tick the Withdraw permission

The reason this one matters is that it caps the size of the loss when a key leaks; the other two settings shrink the probability of a leak. However tight you make your IP whitelist and however carefully you hide the Passphrase, the day some key of yours leaks — a virus on your machine, a breached SaaS platform, an accidental push to a public repo — whether Withdraw was ticked is what decides whether an attacker can simply move the money out.

On Bitget you can cleanly separate trading from withdrawing at the key level — this was one of the things we went through exchange by exchange in our cross-exchange checklist; Bitget is one of the 9 exchanges in the “you can separate them” column (Gate.io is the sole exception). So the difficulty here isn’t a platform limitation; it’s just whether you remember not to tick the box. Bitget adds one extra requirement on Withdraw: the moment you tick Withdraw, you’re forced to bind an IP whitelist. That’s mandatory. Binance and BingX enforce the same rule — it’s a de facto consensus in this small circle of exchanges.

Setting 2: bind an IP whitelist

Bitget’s UTA Quick Start puts it as “For security reasons, it is strongly recommended that you bind an IP address when creating the API Key” — “strongly recommended”, not required (unless you ticked Withdraw). This is where Bitget differs from its peers: Binance and BingX both enforce automatic deletion rules for keys without an IP binding (30 days / 14 days), and Bitget’s docs don’t currently describe any such expiry mechanism. The practical implication for you: Bitget won’t clean up the “forgot to bind IP” keys on a schedule for you, so you have to bind them yourself; otherwise they just sit there indefinitely.

A VPS you set up yourself usually has one fixed IP; a SaaS platform will give you a fixed egress IP (TVSBot publishes one, other tools have varying counts — ask before you wire anything up). The IP whitelist field is clearly present in Bitget’s key-creation UI as a text input; once filled, only requests from those IPs will be accepted.

Setting 3: put the bot key inside a sub-account — this is Bitget’s differentiator

This is where this guide diverges most from the Binance version, and it’s the area where Bitget’s docs actually get into some detail — Bitget lets sub-accounts create and manage their own API keys, without needing the main account to do it for them. This deserves its own H2.

Sub-Account Isolation: Officially Supported on Bitget, but Off by Default

Bitget’s UTA docs spell it out clearly — “Sub-accounts (virtual sub-accounts and standard sub-accounts) can create and manage their own API Keys independently, without requiring the main account to operate on their behalf”. In plain English: you can create a sub-account under your main, transfer funds to it, and have that sub-account create its own API key to run the bot — the main account never has to hold a key. The benefit is isolation: if that sub-account’s key ever goes wrong (leak, runaway strategy, wild orders), the blast radius is capped to the funds in that sub-account, and the rest of the main account is untouched.

But there’s a critical prerequisite that a lot of people miss — this feature is off by default. Bitget’s UTA docs devote a warning paragraph to it: “Prerequisite: The main account must enable the API Key Management permission for the sub-account. This setting is disabled by default. The main account can configure it under sub-account permission settings”. So it’s not that “creating a sub-account is enough” — you have to go into the main account’s sub-account permissions settings and explicitly flip API Key Management on, after which the sub-account can create its own keys. Once enabled, the docs list four things the sub-account can do:

• Create API Key
• View API Key (see the key details)
• Edit API Key permissions
• Delete API Key

The same section adds another sentence: “The main account retains full control and can view, edit, or delete any sub-account’s API Keys at any time” — the main account can look at, modify, or delete any sub-account’s keys whenever it wants. The practical implication: delegating bot-running to a sub-account does not mean you’ve given up control — the sub-account is an operating unit; the main account is always root.

This table isn’t about calling Bitget’s approach better — the two exchanges have different mental models, and each fits different situations. Bitget’s “sub-account manages its own API” is friendlier for a team where different people run different bots (say, you and a collaborator each run one strategy); the main account doesn’t have to be the middleman. Binance’s model — main account holds everything — is actually simpler for a single-person, single-bot retail setup, because everything is in one place. Which one fits depends on your actual situation.

What It Means That Bitget Has No Documented Expiry Rule

Comparing across exchanges makes the weight of this difference clear — Binance deletes keys without an IP whitelist after 30 days of inactivity, BingX after 14 days, OKX after 14 days. In both Bitget’s UTA Quick Start and its Classic API docs, we couldn’t find any auto-expiry rule targeting “keys with no IP” or “keys idle for N days”. That’s the same conclusion we landed on in the cross-exchange checklist.

This difference cuts two ways in practice: the upside is that your bot won’t silently disconnect one morning because the key expired — Bitget won’t do that to you. The downside is that dead keys (say, a key for a tool you stopped using long ago and forgot to delete) will just sit in your API management page forever, one more unattended attack surface. This one is on you: periodically go back to Bitget’s API management page and delete the keys you don’t use anymore — no exchange will do it for you.

The Actual Flow for Creating a Bitget API Key

Bitget’s UI does get redesigned every so often, so this article won’t nail down pixel-level button paths — just the skeleton of steps you can’t skip. Treat what Bitget shows you on the account page at the moment you configure the key as the source of truth. If you’re going the “run the bot from a sub-account” route, the flow adds a couple of steps over creating a single main-account key, but you only do the whole workflow once and it’s stable from there.

[First-time setup: open up the sub-account]
        1. Log into Bitget → avatar (top right) → Sub-Accounts
        2. Create Sub-Account → fill in the sub-account name, email, password
        3. In that sub-account's permission settings, tick API Key Management
           (The docs are explicit: this permission is off by default; you have to flip it on)
        4. From the main account, Transfer the funds you're giving the bot into the sub-account

        [Create the API key: as the sub-account]
        5. Log out of the main account → log in as the sub-account (or use the sub-account switcher)
        6. Top right → API Management → Create API Key
        7. Fill in the Label (e.g., tvsbot-prod, grid-bot-01)
        8. Set a Passphrase (pick an 8-32 character password of your own; forget it and you re-create the key)
        9. Complete 2FA
        10. You receive three credentials: API Key, Secret Key, Passphrase
            (Secret Key is shown once only — copy it immediately)

        [Set permissions: only what you need, never Withdraw]
        11. Click Edit on the key:
            - Tick the Trade categories you need (Spot or Futures, per your strategy)
            - Do NOT tick Withdraw
            - Do NOT tick Transfer (unless your bot needs to move margin automatically)
            - Fill in the IP whitelist (Bitget calls this "strongly recommended" — do it anyway)
        12. Save changes

Secret Key is displayed once and never again — that’s a rule shared across every exchange. Bitget adds a Passphrase on top, so keep that safe too — all three credentials, if leaked, can cause loss of funds according to the docs. Any password manager works (1Password, Bitwarden, macOS Keychain); pasting them into a plain text file, Slack, or email is a habit you only need to learn once to regret.

How to Pick an Automation Tool That Talks to Bitget

Bitget is on our list of exchanges that accept TradingView webhook signals as one of the exchanges with “a functioning official REST / WebSocket API you can wire to for auto-execution”. Which means plenty of tools out there will claim to integrate with it. When you’re picking one, three things are worth asking upfront:

• Does it ask you for Withdraw permission on the key? If yes, walk away from that tool. Placing spot or futures orders technically never requires withdrawal permission — asking for it is an architectural red flag.
• How many fixed IPs does it give you? Most SaaS platforms give 1-3, all of which fit inside Bitget’s IP whitelist field. Some tools use a dynamic egress IP (varies per call) — with those you can’t bind IPs at all, and you’ll have to weigh whether that’s acceptable.
• How do they store your three keys (especially the Passphrase) on their side? Plaintext in a database is a red flag; encrypted storage where the encryption master key lives separately from the database itself is the basic bar worth asking about.

For our part: TVSBot encrypts your three keys with Fernet (AES-128-CBC + HMAC-SHA256), the encryption master key lives only in an environment variable — physically separated from the database itself — and every order is placed by calling Bitget’s API with your own key; we never hold your funds. Our setup docs recommend enabling only the Trade permission and publish a fixed egress IP for you to enter into Bitget’s whitelist, and strongly recommend creating the key in a sub-account rather than the main account. The same checklist applies to any non-custodial tool, not just TVSBot — so even if you end up picking someone else, this section is useful.

Being Honest: What This Article Doesn’t Solve

Even if you nail all three settings above, there are risks this guide cannot make go away, and it’s worth being upfront about them so you have accurate expectations:

First, a breach of the exchange itself is not something API-key-level defence can block — if your funds sit on Bitget, you carry Bitget’s platform risk. That layer is handled by things like the exchange’s Proof of Reserves, insurance fund, and your own choice to spread holdings across platforms and cold wallets — not by how you set up your key.

Second, your own strategy losing money has nothing to do with API key security — this article doesn’t discuss strategy-level risk. No automated trading setup guarantees profit — that’s always true; even the most conservative grid bot or funding-rate arbitrage takes losses in extreme conditions. For strategy-level risk assessment, see our Kelly criterion and position sizing and ATR volatility-based position sizing.

Third, we didn’t perform a full internal-controls audit of Bitget — everything in this article about Bitget’s official rules is drawn from publicly verifiable documentation and account-page content, verified in July 2026. Exchange policies do change without much notice; before you actually configure anything, we recommend visiting Bitget’s official API docs to confirm the current rules yourself.

FAQ