Quickstart
0. Point at your endpoint
Your base URL is issued to you. Every client gets its own endpoint — there is no shared public host — so the first thing you need from your service operator is three values: the base URL, a client id and an api key.
Keep all three in configuration or a secret store — never hard-coded in source, never in a public repo. Every example below reads them from the environment.
Only the host differs between clients. The paths, request bodies, headers and responses in these docs are identical on every deployment, so nothing else in your integration changes.
1. Get a token
Your client id and api key go in headers, not the body. There is no request body.
The token lasts 15 minutes. Every call below sends it as Authorization: Bearer <token>.
2. Create a user
One call mints the user and derives a wallet on every configured chain.
Save the mnemonic now. It is returned exactly once and never stored in plaintext. There is no way to retrieve it later — /seed is permanently disabled. Save the password too: it decrypts the keys and is required to send funds.
The password must be at least 8 characters. The three EVM chains deliberately share one address — it is one account used on Ethereum, BNB Chain and Polygon.
Importing an existing seed
Pass existingSeed instead of letting the service generate one, and /create derives the wallets from your mnemonic. If those wallets already exist, it adopts the existing user rather than failing — and in that case the response contains no mnemonic field at all (you already have it).
mnemonic is therefore conditional. Code like result.mnemonic.split(' ') will crash on an adopted user. Always null-check it.
3. Check a balance
assetId picks the chain and the asset. 21 is USDT on Ethereum — see Asset IDs.
Dust is floored to "0": below 0.00001 of a native coin (0.0001 for BTC), and below 0.0001 of a token. So a "0" balance does not prove the address is empty.
4. Estimate the fee
/fee is the one endpoint that takes raw addresses instead of a userId — it never touches a wallet.
The fee is denominated in the chain’s native asset, not the asset you are sending. Sending USDT on Ethereum costs ETH — so a token wallet still needs a native balance for gas.
On a native send, this fee comes out of the amount. Send "0.5" ETH and the recipient receives 0.5 ETH − fee; exactly 0.5 ETH leaves the wallet. If the recipient must receive an exact figure, add the fee quoted here to the amount you send.
Token transfers behave the other way round: the recipient gets the full amount, and the fee is charged separately in the native coin.
Tron is the exception. It does not return a currency amount, but the resources the transfer will consume: { "bandwidth": 345, "energy": 130285 }. Whatever your account does not already cover with free or staked resources is burned as TRX.
5. Send
A txHash is not a confirmation. It means the network accepted the transaction, not that it succeeded. Poll /txid until status is success or failed.
6. Confirm it landed
While the transaction is unconfirmed, status is pending and date is null. Every chain is normalised to this same row shape, so you write the polling loop once and it works everywhere.
Polling is the only mechanism there is. This API has no webhooks and no callbacks — it will never call you, including when a user receives funds. Read Reliability before you design around it.
Where to go next
- Authentication — the token lifecycle, and API credentials vs the wallet password.
- Asset IDs — the integer for every chain and token, plus minimums and dust.
- Reliability — no webhooks, no pagination, no idempotency key, and how to retry a
/sendwithout sending twice. - Errors — the error envelope and what each status means.
- API Reference — every endpoint, with a request and response example per asset.