OKX and Bybit Subaccount API Permission and IP Binding Controls

Decision Matrix

Source Map

• OKX API Documentation: OKX API guide (okx-api-guide)
• OKX Help Center: Subaccounts, Account Mode, and API Connections FAQ (okx-subaccounts-faq)
• Bybit API Documentation: Create Sub UID API Key (bybit-create-sub-api)
• Bybit Learn: How to Use Bybit Subaccount (bybit-subaccount-guide)

Control Notes

1. Account scope

Account scope is the point where public documentation must become an operating rule. In this package, it means main-account and subaccount keys can address different account surfaces. The practical action is to record the exact account or subaccount selected before generating a key. The unresolved edge is whether a later transfer or managed-subaccount change altered the intended boundary, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, safety guarantee, recovery promise, platform ranking or price implication.

2. Permission scope

Permission scope is the point where public documentation must become an operating rule. In this package, it means read, trade and withdraw permissions change blast radius. The practical action is to start with read-only unless the task requires trade access. The unresolved edge is whether a third-party tool silently requests broader permissions, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, safety guarantee, recovery promise, platform ranking or price implication.

The operating test is narrow.

3. IP binding

IP binding is the point where public documentation must become an operating rule. In this package, it means IP allowlists reduce but do not eliminate API-key risk. The practical action is to bind production keys to expected server addresses where supported. The unresolved edge is whether the automation will run from changing residential or cloud egress IPs, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, safety guarantee, recovery promise, platform ranking or price implication.

The operating test is narrow.

4. Secret handling

Secret handling is the point where public documentation must become an operating rule. In this package, it means passphrases, secret keys and signatures are credential material. The practical action is to store them only in the approved secret channel and never in logs. The unresolved edge is whether debug output or screenshots expose a secret fragment, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, safety guarantee, recovery promise, platform ranking or price implication.

The operating test is narrow.

5. Expiry and rotation

Expiry and rotation is the point where public documentation must become an operating rule. In this package, it means unbound keys can have validity or inactivity constraints. The practical action is to record creation time, last-used state and rotation condition. The unresolved edge is whether a dormant key fails only during live recovery, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, safety guarantee, recovery promise, platform ranking or price implication.

The operating test is narrow.

6. Withdrawal boundary

Withdrawal boundary is the point where public documentation must become an operating rule. In this package, it means withdraw permission is materially different from order management. The practical action is to exclude withdrawal permission unless a separately reviewed workflow requires it. The unresolved edge is whether address-book or risk controls still block the route, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, safety guarantee, recovery promise, platform ranking or price implication.

The operating test is narrow.

Known Unknowns

• whether a later transfer or managed-subaccount change altered the intended boundary
• whether a third-party tool silently requests broader permissions
• whether the automation will run from changing residential or cloud egress IPs
• whether debug output or screenshots expose a secret fragment
• whether a dormant key fails only during live recovery
• whether address-book or risk controls still block the route

Practical Takeaway

OKX and Bybit both document API permissions, subaccount boundaries and IP binding, but their control surfaces are not interchangeable. OKX documentation separates Read, Trade and Withdraw permissions, says API keys can be linked to IP addresses, and explains main-account versus subaccount key creation. Bybit API documentation describes creating a sub-UID API key, read-only mode, permission objects and IP binding behavior. The useful outcome is a pre-trading evidence checklist: account scope, permission scope, IP scope, passphrase or signature secret handling, expiry behavior and a stop rule before any automated order or withdrawal path is enabled. The article stops at the evidence boundary. It helps the reader decide what to inspect next without converting public documentation into a promise that a private account, wallet, API key, pool route, stablecoin balance, tokenized asset or policy framework will work under every future condition.