Bybit API Key Security: Complete Guide — Disable Withdraw, IP Allowlist, Sub-Accounts

You're about to wire a TradingView signal or a trading bot into Bybit for automated execution, and the first thing you have to do is generate an API key — the credential your software uses to talk to the exchange on your behalf. Most people over-grant permissions at this step, because Bybit's permission checkboxes are more granular than Binance's, and the field names — ContractTrade, Wallet — don't map to anything obvious. It's very easy to click through and accidentally include Withdraw. This guide walks through the parts of Bybit's official V5 API docs that actually change your risk exposure, cross-checked against our own API-key permission checklist across 10 exchanges, and focuses on the three settings that matter.

This isn't a comparison of whose security posture is stronger across exchanges — that requires cross-exchange penetration testing and internal audits, we haven't done that work, and this article won't pretend to. The scope is a single API-key layer, because if you get this layer right the money is safe even when a downstream tool gets compromised; get it wrong and everything else you do is decoration.

The First Thing to Understand: The Permission Model (Two Keys, UTA Is Default)

Bybit V5 API authentication uses only two credentials — ACCESS-KEY plus Secret Key, sent as HTTP headers X-BAPI-API-KEY and X-BAPI-SIGN. That's different from Bitget and OKX, which require a third Passphrase, and matches Binance/BingX.

Fewer credentials means one less thing to hide. It also means that if those two leak, an attacker has everything needed to sign requests — there's no third factor left to save you.

Starting from V5, Bybit merged Spot, Derivatives and Options into a "Unified Trading Account" (UTA), and every newly-registered account defaults to UTA mode. The API-layer consequence is that a single key can carry ContractTrade, Spot, Options and Derivatives permissions simultaneously — one key can run three product lines.

Bybit's key-creation UI gives you two options: System-generated or Auto-generated.

The RSA path's upside is "Bybit never holds your private key" — even if Bybit's side is breached, your secret doesn't leak. The downside is extra setup time, and your downstream tool must support RSA signing. If you use a SaaS trading bot, ask the vendor whether they support RSA first; in most situations HMAC is enough.

Three Mandatory Settings: Kill Withdraw, Bind IP, Use a Sub-Account

Setting 1: Don't tick Withdraw under Wallet

This one matters because it decides how bad a leak gets. The other two decide how likely a leak is.

No matter how tight your IP allowlist is, no matter how carefully you hide the Secret Key, the key can still leak — malware, a compromised SaaS vendor, a stray push to a public repo. Whether Withdraw is ticked decides whether the attacker can walk out with the money.

Bybit separates trading and withdrawal cleanly at the key level, which we already verified in our cross-exchange permission checklist — Bybit is one of the 9 exchanges where they can be separated. So this is not a technical limitation — it comes down to whether you remember not to tick the box.

Bybit's official V5 API docs label the Wallet.Withdraw field as "Withdraw(master account)" — the field only exists for master accounts. A sub-account key literally does not have that checkbox.

The "worst case is a few dumb trades" mental model most people hold is not the real worst case. The real path is what we just described: convert first, withdraw second.

Whether IP allowlisting saves you depends on whether the attacker can hit the API from the IPs you set. Plenty of leak scenarios — for example, pushing a config file that contains the IP — leak the IP information alongside the key.

Setting 2: Bind an IP allowlist — Bybit accepts multiple, comma-separated

Bybit's V5 API docs describe the IP field on create-sub-api as "Set the IP bind. example: 192.168.0.1,192.168.0.2. don't pass ips or pass with * means no bind" — multiple IPs separated by half-width commas.

This is handy for SaaS tools, which usually give you 2–3 fixed egress IPs. A self-hosted VPS typically has one fixed IP. On the SaaS side you get fixed egress IPs — TVSBot's dashboard displays the backend IPs you need to paste into Bybit.

Numbers vary by tool — ask before integrating. Tools with dynamic egress IPs can't be locked down with an IP allowlist, and you have to decide whether that trade-off is acceptable.

Setting 3: Put the bot's key in a sub-account — Bybit removes Withdraw at the architecture level

This is the biggest difference from the Binance version of this guide, and the most decisive thing Bybit does at the API-architecture level — the docs state plainly that a sub-account key's Wallet permission "can only be AccountTransfer and SubMemberTransferList". In other words, a sub-account key cannot be ticked for Withdraw even if you wanted to. This deserves its own H2.

Sub-Account Isolation: Bybit Locks Withdraw Out at the API Layer

In the Bybit V5 API docs' create-sub-api (create sub-account API key) chapter, the official definition of the Wallet field in the permissions object reads "Wallet. ["AccountTransfer","SubMemberTransferList"]" — those are the only two valid values, and Withdraw is not one of them.

The same doc's apikey-info endpoint (query key info) defines the full Wallet set as "AccountTransfer, SubMemberTransfer(master account), SubMemberTransferList(sub account), Withdraw(master account)" — Withdraw is explicitly master-account only.

The practical meaning: even if your sub-account key is fully compromised, the attacker has no direct path to withdraw.

The worst they can do is place bad orders or market-sell the sub-account balance into other assets, but they cannot call Bybit's withdraw endpoint — the API rejects it outright due to insufficient permissions. On Binance you rely on your own memory to not tick a box; on Bybit the API architecture enforces it.

Example: your master account holds 100,000 USDT and the bot only runs a 5,000 USDT strategy — move that 5,000 into an isolated sub-account, and the worst case is a 5% loss instead of everything. This principle isn't Bybit-specific, it applies to any multi-asset account setup.

What's Bybit-specific is that the API architecture removes the withdrawal path from sub-accounts entirely — the common "forgot to untick" mistake is blocked for you at the platform level.

This table isn't here to declare Bybit the winner — each exchange has its own logic. Bybit's architectural block on sub-account withdraw is especially forgiving for people who forget or don't know the permission model well. Bitget's "sub-accounts manage their own API" freedom is more useful for teams running different strategies. Binance's master-managed approach is simpler for a single person running a single bot. Pick based on your actual situation.

The 90-Day Expiry Rule: Bybit Has It in Writing, Just Looser Than Binance/BingX

The Bybit V5 API docs' create-sub-api chapter, under the ips field, says verbatim: "No ip bound api key will be invalid after 90 days" — a key without an IP binding expires after 90 days.

The same section adds: "api key without IP bound will be invalid after 7 days once the account password is changed" — even a freshly-created key expires 7 days after you change your password if it has no IP binding.

The apikey-info response includes deadlineDay (days remaining) and expiredAt (expiry timestamp), both of which are only populated when the key has no IP binding or the password was changed.

Bybit's 90 days is the loosest, which means if you plug into Bybit and forget to bind an IP, the bot won't go dark quickly — but it's running exposed for those three months. Conversely, if you did bind an IP, this rule doesn't apply at all and the key stays alive indefinitely.

Verified August 2026, and this article goes stale if Bybit changes the rule. A safer default is to not rely on the exchange's expiry mechanism and to rotate the key manually every 6 months — regardless of whether the exchange helps you, put it on your own schedule.

The Actual Flow for Creating a Bybit API Key

Bybit's UI shifts every so often, so this guide won't hard-code pixel-level button positions — just the step skeleton you have to hit. Assuming you're taking the "bot inside a sub-account" path, the flow is two steps longer than a straight master-account key, but you only do it once and it's stable afterwards.

[Prerequisite: no key creation in the first 48 hours of a new account]
        0. Bybit risk-control rule: newly-registered accounts cannot create API keys
           for the first 48 hours (stated in the help center, lifts automatically)

        [First-time setup: create the sub-account]
        1. Log into Bybit -> avatar top-right -> Sub-Accounts
        2. Create Sub-Account -> pick a sub-account username (6-16 chars, alphanumeric)
        3. memberType = normal subaccount (do NOT pick custodial)
        4. Universal Transfer the funds the bot will use from master to sub-account

        [Key creation: two paths, pick one]
        Path A: log into the sub-account directly and create the key
        5A. Log in as the sub-account -> avatar -> API -> Create New Key
        6A. Pick System-generated API Keys (beginners take this, HMAC)
        7A. Set a note (e.g. tvsbot-prod, grid-bot-01)
        8A. Tick Contract Trade or Spot Trading (depending on your strategy)
        9A. Do NOT tick Withdrawal (the sub-account UI won't even offer it)
        10A. Fill the IP allowlist (multiple IPs, half-width comma separated)
        11A. Pass 2FA -> receive API Key + Secret (Secret is shown ONCE, copy it now)

        Path B: call /v5/user/create-sub-api with a master key
        5B. Use this for automated key provisioning across many sub-accounts
        6B. The permissions object must NOT include Withdraw - Bybit will reject it
        7B. Include an ips array and a note; response returns apiKey + secret directly

The Secret Key is shown exactly once — a rule every exchange shares. Bybit doesn't use a Passphrase, so once you have the API Key and Secret strings safely stored you're done.

Any password manager works — 1Password, Bitwarden, macOS Keychain. Pasting into plain text files, Slack or email is a bad habit that hurts once per lapse.

How to Pick an Automation Tool That Talks to Bybit

Bybit is one of the exchanges we tag as "has an official REST/WebSocket API, can accept automated orders" in our TradingView webhook support by exchange roundup — which means many tools claim to integrate. When choosing one, ask three things:

• Does it require Withdraw permission on the key? If yes, skip this tool — placing spot or futures orders never needs withdraw permission at the API level; asking for it is an architecture red flag.
• How many fixed IPs does it give you? Most SaaS platforms have 1–3; Bybit accepts them comma-separated, all of them fit. Tools with dynamic egress IPs simply can't be locked with an IP allowlist.
• How is your Secret Key stored on their side? Plaintext database storage is a red flag. Encrypted at rest, with the master encryption key stored separately from the database, is the baseline worth asking about.

For what it's worth: TVSBot encrypts your API Key and Secret with Fernet (AES-128-CBC + HMAC-SHA256), keeping the master encryption key in an environment variable — physically separated from the database itself.

Every order call goes directly against Bybit's V5 API using your own key. We never hold your funds. The dashboard displays the backend IPs you paste into Bybit's allowlist, and the setup docs recommend ticking only Contract Trade + Spot Trading, with Withdrawal left off.

The same checklist applies to any non-custodial tool, not just TVSBot — so if you end up choosing another vendor, this section still holds up.

The Honest Section: What This Guide Doesn't Fix

Even with all three settings dialled in correctly, there are risks this guide cannot eliminate, and it's here so your expectations line up with reality:

First, an exchange being compromised itself has no API-key-level defence — money on Bybit is exposed to Bybit's platform-operations risk. That layer is handled by the exchange's Proof of Reserves, insurance fund, and by you spreading holdings across multiple venues or cold wallets — nothing to do with how you set up keys.

Second, your own strategy losing money has nothing to do with API-key security. This guide doesn't cover strategy risk at all. Even the most conservative grid bot or funding-rate arbitrage loses in extreme conditions. For strategy-level risk sizing, see Kelly criterion and position sizing and ATR-based dynamic position sizing.

Third, we haven't audited Bybit's internal controls. Everything in this article about official Bybit rules is drawn from the publicly-verifiable V5 API docs and help center, as of August 2026. Exchange policies change with little notice — before actually configuring anything, go verify the current rules on Bybit's official API docs page.

FAQ