ذرائع کی جانچ پر مبنی تحقیق: OKX
مضمون کا متن تصدیق شدہ انگریزی اصل میں دکھایا گیا ہے۔ ذریعہ جائزے کے بعد ترجمہ شامل کیا جائے گا.
Verified Fact Boundary
1. OKX says subaccounts can be used to separate trading strategies, manage multiple trading bots and control risks independently. 2. OKX says standard users can create up to five subaccounts. 3. OKX says API key creation includes choosing the account or subaccount, selecting required permissions, creating a passphrase and confirming with 2FA. 4. OKX says available API permissions include Read, Trade and Withdraw, with Withdraw allowing withdrawals via API and requiring caution. 5. OKX says IP addresses help secure API keys, up to 20 addresses can be linked per key, and the API passphrase cannot be recovered if lost.
کم دکھائیں
Decision Matrix
مضمون کا جدول: افقی اسکرول کریں، یا جدول کے علاقے پر فوکس کر کے تیر والے بٹن استعمال کریں۔
| Check | What it means | Practical action | Unknown to keep explicit |
|---|---|---|---|
| Subaccount purpose | risk separation for strategies or bots | create a subaccount only when separation has a job | regional feature availability |
| Account mode | which products and markets the account can use | configure mode before API use | mode not changeable via API |
| Key account | main account or chosen subaccount | select the intended account before creating the key | wrong account binding |
| Permission set | Read, Trade or Withdraw | start with Read and add only necessary permissions | withdrawal misuse |
| Passphrase | secret created during API setup | store it securely because it cannot be recovered | lost secret rotation |
| IP binding | network allowlist for API use | bind trusted IPs and document each one | dynamic IP changes |
| 2FA confirmation | interactive confirmation before creation | complete 2FA in the official OKX flow | phishing prompt |
| Expiry behavior | unbound trade or withdrawal keys may expire after inactivity | prefer IP-bound keys for long-running tools | policy changes |
| Third-party tools | external bots or platforms using the key | avoid withdrawal permission for shared tools | vendor custody of secrets |
| Stop rule | when setup should pause | stop if asked for seed phrases, remote access or unnecessary Withdraw permission | account-specific eligibility |
Source Map
- OKX: Subaccounts, Account Mode, and API Connections FAQ (okx-subaccounts)
- OKX: OKX API FAQ (okx-api-faq)
- OKX: OKX API Documentation (okx-api-docs)
- OKX: Terms of Service (okx-terms)
Control Notes
1. Subaccount purpose
Subaccount purpose is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means risk separation for strategies or bots. The useful action is to create a subaccount only when separation has a job. The unresolved edge is regional feature availability, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.
For an operator, subaccount purpose should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material. The record can stay simple: the official source URL, the date checked, the product or network under review, and a non-secret note describing why the next step is acceptable. Screenshots should avoid balances, identity documents, API keys, recovery phrases, private keys, passphrases, verification codes and support-ticket private data.
2. Account mode
Account mode is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means which products and markets the account can use. The useful action is to configure mode before API use. The unresolved edge is mode not changeable via API, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.
For an operator, account mode should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.
3. Key account
Key account is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means main account or chosen subaccount. The useful action is to select the intended account before creating the key. The unresolved edge is wrong account binding, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.
For an operator, key account should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.
4. Permission set
Permission set is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means Read, Trade or Withdraw. The useful action is to start with Read and add only necessary permissions. The unresolved edge is withdrawal misuse, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.
For an operator, permission set should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.
5. Passphrase
Passphrase is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means secret created during API setup. The useful action is to store it securely because it cannot be recovered. The unresolved edge is lost secret rotation, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.
For an operator, passphrase should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.
6. IP binding
IP binding is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means network allowlist for API use. The useful action is to bind trusted IPs and document each one. The unresolved edge is dynamic IP changes, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.
For an operator, ip binding should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.
7. 2FA confirmation
2FA confirmation is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means interactive confirmation before creation. The useful action is to complete 2FA in the official OKX flow. The unresolved edge is phishing prompt, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.
For an operator, 2fa confirmation should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.
8. Expiry behavior
Expiry behavior is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means unbound trade or withdrawal keys may expire after inactivity. The useful action is to prefer IP-bound keys for long-running tools. The unresolved edge is policy changes, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.
For an operator, expiry behavior should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.
9. Third-party tools
Third-party tools is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means external bots or platforms using the key. The useful action is to avoid withdrawal permission for shared tools. The unresolved edge is vendor custody of secrets, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.
For an operator, third-party tools should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.
10. Stop rule
Stop rule is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means when setup should pause. The useful action is to stop if asked for seed phrases, remote access or unnecessary Withdraw permission. The unresolved edge is account-specific eligibility, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.
Known Unknowns
- regional feature availability
- mode not changeable via API
- wrong account binding
- withdrawal misuse
- lost secret rotation
- dynamic IP changes
- phishing prompt
- policy changes
- vendor custody of secrets
- account-specific eligibility
Practical Takeaway
The safest version of this article is the one that stays boring and exact. A safe OKX subaccount API setup starts with account separation, then key creation, permission selection, passphrase custody and IP restriction. OKX says subaccounts can separate strategies, manage multiple trading bots and control risks independently; API keys connect external tools for reading account data and executing trades. OKX's subaccount FAQ says users choose the account or subaccount, permissions and passphrase, then confirm with 2FA. Its API FAQ says IP addresses help secure a key, up to 20 addresses can be linked per key, passphrases cannot be recovered, and API keys with transaction or withdrawal permissions that are not bound to IP can be deleted after 14 days of inactivity. This tutorial is a safety workflow, not an instruction to grant withdrawal access. The user outcome is a clearer next inspection step, not a promise that a platform, API, transfer route or tokenized asset will work under every future condition.
موضوعی مراکز اور اوزار:ایکسچینج API اور مارکیٹ ڈیٹا کنٹرولز
ذرائع
04- Subaccounts, Account Mode, and API Connections FAQ · okx.com
- OKX API FAQ · okx.com
- OKX API Documentation · okx.com
- Terms of Service · okx.com