White-Label Crypto Wallet API — A Practical Guide

A white-label crypto wallet API lets your app give every customer their own crypto wallet, under your brand, without building or securing the wallets yourself. This guide shows how such an API is used in practice, step by step.

#What you get

With one integration, each of your customers gets:

• their own permanent wallet address on TRON for USDT, USDC and TRX;
• deposits that are detected, confirmed and credited automatically;
• a balance your app can read at any time;
• payouts to any TRON address.

Your app shows everything in your own design. The API stays behind the scenes.

#Step 1: Get a sandbox key

Start in the sandbox. It works exactly like the live API, but with test money. You can create users, simulate deposits and send test payouts without risk.

#Step 2: Create a user

When a customer signs up in your app, create them on the wallet API with your own user ID:

POST /v1/users
{ "external_user_id": "10482" }

The answer includes the user's wallet address. Show it in your app as their deposit address. It never changes, so customers can save it, and asking again with the same ID returns the same address.

#Step 3: Receive deposits

When a customer sends USDT to their address, the platform:

1. sees the transaction on the blockchain;
2. waits for enough confirmations to be safe;
3. credits the customer's balance;
4. sends your app a webhook.

Deposits are free, so the customer receives the full amount.

#Step 4: Verify every webhook

Every webhook carries a signature in the x-cryptoinfra-signature header. It is an HMAC-SHA256 of the raw request body, made with your endpoint's secret. Always check it before trusting a webhook:

expected = HMAC_SHA256(secret, raw_body)
if expected != header: reject

This stops anyone from faking a deposit by sending your server a made-up request.

#Step 5: Send payouts

When a customer wants to withdraw:

1. ask for the exact fee for that send;
2. show the customer the amount and the fee;
3. send the payout with an idempotency key.

The idempotency key is important. If your request times out and you send it again with the same key, you get the first payout back instead of a second one. One request, one payment, always.

#Step 6: Add your own fee

You can add your own fee to payouts. It is charged on top and paid straight into your own balance. You also earn a share of the platform's fee on every operation automatically.

#Good practices

• Store the user's address, but read balances from the API, not from your own copy.
• Treat webhooks as signals, then read the latest state from the API before acting on large amounts.
• Always use idempotency keys for payouts.
• Show fees before sending. Never let a customer discover a fee afterwards.
• Test failure cases in the sandbox, such as a payout to an invalid address.

#Security behind the scenes

A good wallet API protects the money you cannot see:

• signing keys are kept apart from the servers your app talks to;
• every change in the dashboard needs an authenticator code and an email code;
• balances are checked against the blockchain regularly.

Read more on our security page.

#Start building

Sign up free, get a sandbox key and follow the quickstart. For AI coding tools, the docs also include an MCP server and an llms.txt file, so your assistant can read the API too.