BingX API Key Security: The Complete Guide
Disable Withdraw, Whitelist Your IP, and the 14-Day Idle Expiry

The first thing you do when hooking a TradingView signal or a trading bot up to BingX for auto-execution is create an API key. Ninety percent of people grant too much permission at this step—usually by following a Binance tutorial they found online and clicking the same checkboxes, forgetting that the two exchanges don't share a permission model. This guide takes what BingX's own API docs say, plus what our own ten-exchange API key permissions checklist has already verified, and boils it down to a BingX-specific version. Three things that actually move your risk: which permission to skip, whether to bind an IP, and one idle-expiry rule most people have never heard of.

This guide doesn't compare BingX and Binance on which does security better—that would take cross-exchange testing and an audit of both companies' internal practices, which we haven't done. It also doesn't teach you how to build a trading strategy on BingX—this is only about the API key layer. The reason to keep it that narrow is simple: get this one layer right and even a compromised downstream tool can't move your funds; get it wrong and every other defense you build is decorative.

BingX's API Key Permission Model: What You Can and Can't Toggle

BingX's API key creation flow, like most centralized exchanges, gives you independent checkboxes for each permission—not the Read and Write vs. Read Only binary you get on Gate.io. That's a good thing, because it means you can scope a key down to exactly what its job requires. The permission list, per BingX's official API docs and the account-side API management page (verified July 2026), looks like this.

There's an easily-missed column on this table: Read is not an independent checkbox. The moment you check Spot trading or Perpetual Futures trading, the ability to read account and market data comes along for the ride. That's different from Binance, which exposes Enable Reading as its own separate checkbox—so if you genuinely want a “read but not write” key on BingX (for a monitoring script or a dashboard, say), the BingX way to do it is to check none of the trading categories at all. That's the default read-only state.

Three Settings You Must Get Right: Kill Withdraw, Bind IPs, Enable 2FA

Setting one: don't check the withdrawal permission

This one matters because it decides how bad a leak actually is. The other two decide how likely a leak is. However tight your IP whitelist, however many layers of 2FA you stack on the account, the day a key escapes—malware on your machine, a breached SaaS platform, a public repo push you didn't catch—whether Withdraw was checked decides whether the attacker can walk the money out the door.

On BingX, trading and withdrawal can be separated cleanly at the key level. Our cross-exchange checklist confirmed this exchange by exchange: nine of ten exchanges we checked support the separation, and Gate.io is the sole exception. BingX sits in the “can be separated” nine. So the difficulty here isn't technical—it's whether you remembered not to check the box.

Setting two: bind an IP whitelist

BingX's rule on IP whitelisting is that enabling withdraw requires an IP binding—that part is mandatory. The other permissions (trading, transfer, sub-account management) leave it optional. A single key can bind up to 20 IPs. That ceiling is more than enough for almost every real setup: a VPS you run yourself is usually one static IP, and if you use a SaaS platform they'll give you a fixed egress IP or two (TVSBot gives you one; other tools vary, so ask before you connect).

Here's the BingX-specific trap worth flagging up front: if your key has no IP binding at all, you lose a layer of defense and—more importantly—you trigger the 14-day idle-deletion rule we'll cover next. Bind an IP and that rule doesn't apply. So on BingX, whitelisting an IP isn't just “+1 security”—it's also “prevent silent bot disconnect,” and that's the piece Binance users migrating over miss most often.

Setting three: 2FA on the main account, address whitelist

How safe your API key is has an indirect relationship with how well protected your main account is. What follows is strongly recommended but not the point of this article—defer to what BingX's account page actually shows at the moment you set it up: enable 2FA on the main account, turn on email alerts for unusual logins, and add allowed withdrawal addresses to the account-level whitelist (a different thing from the API key's IP whitelist—this is the account-level setting that restricts “funds can only go to these addresses”).

This section is short on purpose—these are generic account security practices, not BingX-specific ones. We haven't sat inside a BingX account and walked through the current 2FA, address whitelist, and login notification UIs screen by screen, so we're naming the features rather than pointing at buttons. Defer to what the BingX account page shows when you get there.

The 14-Day Idle Rule: BingX's Silent Disconnect Trap

This one matters because your bot will stop working without you knowing, and no error message will tell you it happened. BingX's official rule: if a key holds any of trading, transfer, or sub-account management permission, and doesn't have an IP whitelist bound, it gets auto-deleted after 14 days of idleness. Keys with an IP bound, and pure read-only keys with no permissions checked, are both exempt.

Binance is 30 days, BingX is 14—cut in half—which is why you can't take a Binance tutorial and click through it on BingX. “Idle” here means “no API calls during that window”, not “you didn't log in.” That matters because as long as your bot is alive and hitting the API (even a once-a-minute read), the 14-day clock never accumulates.

The Actual Flow for Creating a BingX API Key

The official UI ships changes now and then, so this skeleton is the steps you have to go through, not a pixel-perfect click path. Defer to what BingX's account page shows when you get there.

Log in to BingX
          → Top-right avatar / account menu
          → API Management (or the API tab inside account settings)
          → Create API Key
          → Fill in Label (e.g. tvsbot-prod, grid-bot-01)
          → Complete 2FA verification
          → Receive the API Key and Secret Key (the Secret is shown once; copy it now)
          → Click the key to enter Edit:
              - Check the trading category you actually need (Spot or Perpetual)
              - ❌ Do NOT check Withdrawal
              - ❌ Do NOT check Sub-account management
              - Fill in the IP whitelist (recommended even if you didn't enable Withdraw)
          → Save changes

The Secret Key only shows once—that's a rule shared by every exchange, not a BingX quirk. The moment it appears, copy it into a password manager (1Password, Bitwarden, macOS Keychain, any of them). Pasting it into a plaintext file, Slack, or email is a habit you learn once and pay for once.

Running Bots in a Sub-Account: Worth Considering, Not Required

BingX supports a sub-account architecture—you can create sub-accounts under your main account, each with its own API keys. The upside is blast-radius isolation: if a bot's key ever misbehaves (leak, runaway strategy, orders going haywire), the damage is capped at whatever's in that sub-account, not the rest of your main balance.

BingX's official docs cover this under Sub-account Management, listing endpoints like Create Sub-account, Create Sub-account API Key, Query API KEY Permissions, and Freeze/Unfreeze Sub-Account—which tells you the architecture is officially supported with a full API surface for managing it. But as far as we can find, BingX's official docs don't say bots must run in a sub-account. It's a best practice, not a rule. So whether to use one comes down to whether your bot's balance is large enough that another isolation layer is worth the setup.

How to Vet a Tool That Connects to BingX

BingX is currently on our own list of exchanges accepting TradingView webhook signals as one of the “has an official REST/WebSocket API you can connect for auto trading” entries—which means plenty of tools out there claim to work with it. Three questions worth asking a tool before you hand it a key:

• Does it require the withdrawal permission on your key? If yes, skip the tool—spot and futures order placement technically never needs withdrawal, so asking for it is an architectural red flag.
• How many fixed IPs does it give you, and will they fit inside BingX's 20-IP cap? Most SaaS give you 1–3, which fits BingX with room to spare; some tools use dynamic egress IPs (a different address on every call), and those can't be whitelisted—you'll have to weigh whether you can live with that.
• How does it store your key on their side? Plaintext in a database is a red flag; encrypted at rest with the master key held separately from the database itself is the baseline worth asking about.

For our own part: TVSBot encrypts stored API keys with Fernet (AES-128-CBC + HMAC-SHA256), with the master key held only in environment variables and physically separated from the database itself. Every order is placed directly against the exchange's API using your own key—we never take custody of your funds. Our setup docs recommend a trade-only key and publish a fixed egress IP you can add to your BingX whitelist. That same checklist applies to any non-custodial tool, not just ours—so even if you pick a different platform in the end, this section is still useful.

The Honest Section: What This Guide Doesn't Fix

Even with all three of the settings above dialed in correctly, there are risks this tutorial cannot eliminate for you. Naming them up front so you have the right expectations:

First, an exchange itself getting breached is not something API key hygiene can defend against. Once your assets sit on BingX, you're exposed to BingX as a platform. That layer is handled by things like Proof of Reserves, insurance funds, and your own decision to spread balances across multiple exchanges or cold storage—not by how you configured a key.

Second, your strategy losing money is not an API key security problem. This article says nothing about strategy-level risk. Backtest results don't predict future returns, that's always true; even the most conservative grid bot or funding-rate arb blows up in extreme conditions. For strategy-side risk analysis see our Kelly Criterion and position sizing and ATR-based volatility position sizing.

Third, we haven't audited BingX's internal practices. Everything we say about BingX's official rules is drawn from publicly verifiable documentation and account pages, verified July 2026. Exchange policies change without much notice—before you actually set anything up, take another pass through BingX's current official API docs to confirm the rules haven't moved.

FAQ