Skip to main content
POST
Adds a wallet address to your withdrawal whitelist — the address can then receive withdrawals. This is the security chokepoint of the egress (outbound money movement) model: adding a whitelist entry is itself MFA-gated, so an attacker with a stolen session cannot add their address and drain funds in one step.
Every call needs a fresh MFA factor (passkey, TOTP, or emailed code) in the body. Without one, the call fails with VERIFICATION_FAILED — status 400 when the factor is missing, 401 when it is wrong or already used, 403 when TOTP is not enrolled, 429 after too many attempts.
Cookie-authenticated writes also need an Origin header. Any non-GET request that carries the liddie_access session cookie is checked against the allowed dashboard origins; a bare cURL that sends only the cookie is rejected with 403 {"ok":false,"error":{"code":"CSRF_ORIGIN_MISMATCH","message":"Forbidden"}} before the handler runs. The snippet below is shown for shape — from a browser the dashboard sends the origin for you; from a script, prefer an API key where the endpoint accepts one.
The example request omits the MFA fields, so the server rejects it with VERIFICATION_FAILED.

Authorization

Dashboard-only (JWT session). Roles: merchant_admin / merchant_member / super_admin, with team permission whitelist:manage. The body must additionally carry a fresh MFA factor (passkey / TOTP / emailed code); request an email code via Send whitelist email code. Rate limit: 10/min. Calling with an API key fails with 401 {"error":"Invalid or expired token"} — the key is not a JWT.

Parameters

string
required
Ticker of the currency this address receives, e.g. LTC. 2–20 characters.
string
required
The wallet address to whitelist. 4–256 characters.
string
Routing tag for tag-based currencies (XRP): XRP only, and a canonical uint32: digits only, 0–4294967295, no leading zeros. "12345" ✓, "9999999999" ✗ (out of range), "0123" ✗ (leading zero). The route’s ^[0-9]{1,10}$ is only the first gate — the service rejects the rest. It becomes part of the entry’s identity — the same address with a different tag is a different entry.
string
A human-readable name for the entry, e.g. "Cold wallet". Max 64 characters.
string
The single-use emailed code.
string
A 6-digit code from your authenticator app — an alternative to emailCode. Backup codes are not accepted here: the field is validated against ^[0-9]{6}$ and backup codes are 16 hexadecimal characters. They work only at login (POST /2fa/validate). If you have lost your authenticator, request an emailed code instead.
object
WebAuthn assertion, used together with challengeKey.
string
Accompanies passkeyResponse.
Request a fresh single-use code via Send whitelist email code right before this call, then include it in the body as the email-code verification factor — alternatively, an OTP or passkey assertion satisfies the MFA requirement.

Response

201 Created. The body echoes only the new entry’s id — nothing else about the entry is returned.
201 Created
boolean
true on success.
string
The whitelist entry id. Pass it to Remove whitelist entry to undo this.

Errors

Every WHITELIST_ADD_FAILED fires AFTER the MFA factor is verified, so an emailed code is already spent when you see one. Request a fresh code before retrying — resending the same body will fail on the code, not on the original problem.

See also