API Management
LTP issues two categories of API key, and they are not interchangeable — they come from different systems and control different things. Both are managed in Account → API Management in the LTP client.
| Category | Issued by | What it controls |
|---|---|---|
| LTP API | LTP | Transfers, withdrawals, and RapidX trading — anything that moves assets inside the platform. This is the key the endpoints in this reference expect |
| Exchange API | The exchange, provisioned by LTP | Trading at the venue, scoped to a single DMA sub-account. No access to LTP's transfer system |
The dividing line is the transfer system: only an LTP API key can move assets between your accounts or send them out of LTP.
Key Scope
Every LTP API key has a scope — the set of accounts it may touch. Scope is fixed when the key is created and can never be changed afterwards; permissions can be edited at any time. If you need a wider scope, create a new key.
| Form | Scope | Who can create it |
|---|---|---|
| User-level | Every account you hold — Funding Account, all DMA sub-accounts, Main Portfolio, all Sub Portfolios | Main user only |
| Sub-user-level | Only the trading resources assigned to that sub-user | Main user, on behalf of a sub-user |
| Sub Portfolio-level | One single Sub Portfolio | Main user, or the sub-user that Portfolio is assigned to |
In the client's create form the first two appear as All Accounts (user-level API access) and the third as RapidX Sub Portfolio (portfolio-level API access).
Your user-level key is also your Main Portfolio key. When you register with LTP, that identity is your RapidX Main Portfolio — there is no separate Main Portfolio key to create. The right to move assets across accounts comes from the main user identity, not from any individual Portfolio.
Permissions
| Permission | What it allows |
|---|---|
| Read | View balances, positions, and order history within the key's scope |
| Transfer | Move assets between accounts within the key's scope |
| Withdraw | Send assets to an external address |
| Trade (RapidX) | Place and manage RapidX orders |
Two rules that are easy to miss:
Readis always on. You cannot create a key without it and cannot remove it later.- A key carrying
WithdraworTrademust have an IP whitelist. Up to 20 addresses, comma-separated, editable at any time. Requests from any other address are rejected with2001.
What Each Key Can Reach
Scope and permissions combine, and the result is not always obvious:
| Account type | User-level key | Sub-user-level key | Sub Portfolio key |
|---|---|---|---|
| Funding Account | Read / Transfer / Withdraw | — | — |
| DMA sub-accounts | Read / Transfer / Withdraw | Assigned ones only | — |
| RapidX Main Portfolio | Read / Transfer / Withdraw / Trade | — | — |
| RapidX Sub Portfolios | Read / Transfer / Withdraw | Assigned ones only | The one it is scoped to |
Tradelands on exactly one row for a user-level key: Main Portfolio. To trade a Sub Portfolio you need that Portfolio's own key.- A sub-user-level key cannot trade at all —
Tradeis unavailable on both of its rows. - On a Sub Portfolio key,
Transfermeans moving that Portfolio's own assets between the venues inside it. It cannot reach another Portfolio or a DMA sub-account; that needs a user-level key.
Assigning Sub Portfolios to sub-users is coming soon.
Limits
| Limit | Value |
|---|---|
| Keys per user (you, or any one sub-user) | 10 |
| Keys per Sub Portfolio | 10 |
| Total user-level and sub-user-level keys across the account | 500 |
Sub Portfolio keys do not count towards the 500, so in practice the per-entity limit of 10 is the one you meet first.
Secret Key
The Secret Key is shown once and only once. Creating a key does not reveal it — you reveal it explicitly from the key's detail panel in the client, it stays visible for about 10 minutes, and after that it can never be shown again to anyone, including LTP support.
Store it the moment you reveal it. If you lose it there is no recovery path: delete the key and create a new one.
Two Rules That Affect Integrations
A key belongs to the Portfolio, not to whoever created it
A Sub Portfolio's keys travel with the Portfolio. Assign the Portfolio to a sub-user and all of that Portfolio's existing keys go with it — including keys the main user created. Unassign it and that access is withdrawn. Access is decided by "is this Portfolio assigned to you", never by "did you create this key".
The one exception is a sub-user's own sub-user-level key: they can use it but not edit or delete it.
A Sub Portfolio key has no identity, so Withdraw on it is unrestricted
Withdraw on it is unrestrictedA sub-user-level key belongs to a specific person, so every request is attributable and withdrawals are constrained to the addresses made available to that sub-user.
A Sub Portfolio key belongs to the Portfolio, not to a person — its User field is empty. With no identity attached there is nothing to narrow destinations against.
A Sub Portfolio key carrying
Withdrawcan send to any address in the account's withdrawal whitelist, not to a sub-user's subset. Assigning the Portfolio to a sub-user does not restrict this, because the restriction mechanism relies on identity and there is none. To give a sub-user withdrawal capability, use a sub-user-level key withWithdrawinstead.
Only a main user can grant Withdraw on a Sub Portfolio key — the permission is unavailable to sub-users both when creating and when editing a key.
Why Your Key Might Be Rejected
| Code | Meaning | What to check |
|---|---|---|
2000 | API verification failed | Signature. Parameters must be sorted alphabetically and signed with raw, un-encoded values — see Authentication |
7000 | Nonce is invalid | Your nonce is more than 30 seconds from server time. Sync your clock via NTP |
2001 | IP not on the key's whitelist | Your egress IP changed, or the key carries Withdraw / Trade and has no whitelist configured |
2002 | API authorization invalid | The key is missing the permission the endpoint requires |
100018 | API key not exist | Wrong or empty X-MBX-APIKEY, or the key was deleted |
100041 | API key has been frozen | The key was frozen in the client. Frozen keys keep their configuration but stop working until unfrozen |
401061 | Order placement forbidden for this portfolioId | The Portfolio is outside this key's scope — a Sub Portfolio key can only trade its own Portfolio |
For the full list, see Error Codes.
Exchange API
An Exchange API key is not an LTP key. It is a native key on the exchange itself — Binance, OKX, Bybit, Gate and others — that LTP provisions on your behalf and attaches to one of your DMA sub-accounts. LTP surfaces it in API Management so you can manage everything in one place, but the key lives at the venue.
- It trades at the exchange for the single DMA sub-account it is attached to, and can move assets within that sub-account as the venue allows.
- It cannot perform any LTP-level operation — no transfers to your other sub-accounts, no transfers from your Funding Account, no withdrawals through LTP.
- Permissions are set by LTP when the key is provisioned and are not editable from the client. You can edit its IP whitelist, and reveal its Secret Key once — the same one-time rule as LTP keys.
To transfer assets between DMA sub-accounts, or between a DMA sub-account and any other LTP account, you need an LTP API key. Exchange-native keys have no access to LTP's transfer system.
Updated 11 days ago