All
Filter by:
How do I deposit cash into my account?
I need help with account verification
Why can't I access my account?
Are there any crypto withdrawal fees?
I need help signing into my account
API Keys
API keys give automated systems, trading bots, operational scripts, reporting pipelines, and FIX trading sessions, programmatic access to your Organization’s accounts. This article covers the API key permission model, how keys map to accounts, how Organization governance applies to key-initiated operations, and how key administration itself is governed.
API keys are not Members with credentials. They carry their own, simpler permission model:
Member | API key | |
|---|---|---|
Authentication | Individual sign-in with 2FA | API key credentials |
UI access | Yes | No, API only |
Permission model | Workflow Profile + Account Roles | API key permissions applied to selected accounts |
Per-account variation | Yes, roles can grant different permissions on different accounts | No, the key’s permissions apply uniformly to all its selected accounts |
Can start withdrawal and transfer requests | Yes, when permitted | Yes, when permitted |
Can approve requests | Yes, except their own | Never |
Administrative workflows | Yes, per their Workflow Profile | Never |
The two models are deliberately separate. Members get roles, profiles, and per-account granularity because humans accumulate varied responsibilities. Keys get a flat scope-plus-accounts model because automation should be narrow, uniform, and easy to audit at a glance.
An API key combines two selections: what it can do (its permissions) and where (its accounts).
Permissions
Group | Permission | What it allows |
|---|---|---|
Funds | Query funds | View balances and funding status |
Deposit | Generate deposit addresses and view deposit history | |
Withdraw | Start withdrawal requests (see “Governance and API keys”) | |
Earn | Allocate and deallocate Earn products | |
Orders | Query open orders | View open orders and active trades |
Query closed orders | View historical orders and completed trades | |
Create and modify orders | Place and modify orders | |
Cancel and close orders | Cancel open orders and close positions | |
Addresses | Add withdrawal address | Start requests to add whitelisted addresses |
Update withdrawal address | Start requests to change whitelisted addresses | |
Data | Query ledger | View transaction and ledger history |
Export data | Export account data for reporting and reconciliation |
Account mapping
Each key is mapped to one or more accounts, chosen when the key is created and editable later. The key’s permissions apply uniformly across every selected account:
- A key with Query funds and Create and modify orders on two selected accounts can read balances and trade on both, and touch nothing else.
- There is no per-account variation within a key. If your automation needs to trade on one account but only read another, use two keys. This keeps each key’s blast radius obvious.
FIX connectivity
Keys with order permissions support FIX connectivity for spot trading alongside the REST and WebSocket APIs. A FIX session carries the same permissions and account mapping as the key behind it: it trades only on the key’s selected accounts, within the key’s permissions. Firms running FIX order flow typically dedicate a key per session, scoped to the accounts that desk trades.
Note:
WebSocket trading on accounts other than the main account is not yet available to API keys, it remains an Owner-only capability for now. Automated order flow on additional accounts should use REST or FIX. See Availability and limitations.
Security settings
Setting | Description |
|---|---|
Key expiration | Optional date after which the key stops working |
Query start / end date | Bound data queries to a date range |
WebSocket connections | Enable or disable real-time streaming |
Custom nonce window | Replay-protection tuning for high-frequency use |
IP restrictions | Limit key usage to specific IP addresses or CIDR ranges |
Tip:
Give every key the narrowest permissions, fewest accounts, and tightest IP restrictions that let it do its job. Separate keys per system, one for the trading bot, one for reporting, keep revocation surgical.
Organization governance applies to what keys do, and to how keys are managed.
What keys do
The two-category rule for Members applies to keys the same way:
- Direct operations execute immediately. Trading, Earn, balance queries, ledger queries, and data exports complete on the spot, within the key’s permissions and accounts.
- Governed operations create requests. A withdrawal or address change started by a key enters the same pipeline as one started by a Member: the workflow’s policy decides whether it completes immediately or waits in the approval queue for human review.
A key can only ever start governed requests. Keys never hold Approve, separation of duties requires a human Member for every approval, and a script cannot stand in for that judgment. When the Withdrawal Request policy requires two approvals, a key-initiated withdrawal waits for two Members, exactly as a Member-initiated one would.
Build automation around that asynchrony: a successful API call means the request was created, not that funds moved. Track the request until it completes, and account for the current limitation that a pending request does not set funds aside, if the balance moves during review, the approved request fails and needs to be resubmitted. See Keep the funds available until approval.
Keys also have no path into the administrative workflows. Managing team access, API keys, accounts, addresses (beyond starting address requests), and policies is Member-only.
How keys are managed
Creating, editing, and revoking API keys is a governed operation under the dedicated Manage API Keys workflow, separate from Manage Team & Access. The separation matters in two ways:
- Different administrators. You can let an operations engineer manage keys without any ability to change Members’ access, and vice versa.
- Different policies. Key management can carry its own approval requirements. Many Organizations require independent approval to create or modify a key, a new credential is a new way into your accounts, while keeping revocation fast.
- Go to API keys and select Create key.
- Name the key after its purpose, the system it serves and what it does, so its function is obvious in reviews and security events.
- Select the key’s permissions.
- Select the accounts the key operates on. The permissions apply to all of them uniformly.
- Configure security settings: expiration, IP restrictions, nonce window.
- Review and confirm. If the Manage API Keys policy requires approval, the request waits for the required approvals before the key is issued.
Caution:
The key’s secret is shown once, at creation. Store it securely before leaving the screen, it cannot be retrieved later.
Editing a key’s permissions or accounts, and revoking a key, follow the same governed path.
Troubleshooting
The call created a withdrawal request, and the Withdrawal Request policy is holding it for approval. Check the Requests page, the request appears there with the key as initiator, waiting for the required Member approvals. This is the governance model working as intended: automation proposes, humans approve.
If the request was approved and the funds still did not move, check whether the source balance covered the amount at completion time, a pending request does not reserve funds, so activity during review can cause an approved request to fail. Resubmit once the balance is back.
The failing account is not in the key’s account mapping. A key acts only on its selected accounts. Edit the key to add the account, noting that the key’s full permission set will apply there, since keys have no per-account variation. If that is too broad, create a second key scoped to the new account.
A single key cannot vary permissions by account. Create two keys: a trading key mapped to account A and a read-only key mapped to account B. Narrower keys are also easier to audit and safer to revoke.
The Manage API Keys workflow likely requires approval, and the request is still pending. The key is issued, and its secret shown, only after the required approvals are collected. Check the request’s status on the Requests page.
No. Approval always requires a human Member. This is a system rule, not a configurable policy, it is what makes multi-party approval meaningful when automation initiates fund movements.