Errors
Every failure returns the same shape, with the HTTP status repeated in error as a string:
message is always safe to show a user and safe to log. Internal detail never appears in it — when something breaks on our side, the specifics go to our audit log against the requestId, and you get a generic message. Quote the requestId when you report a problem and we can pull up the exact request.
Status codes
The two that matter
401 on /send means the password was wrong — nothing was broadcast, so fixing it and retrying is completely safe. But a 500 or a timeout on /send is ambiguous: the transaction may have been signed and broadcast before the failure reached you. Never auto-retry it, and do not assume it failed just because it isn’t in /transactions yet. Follow the procedure in Reliability — retrying blind is how you send twice.
A 200 from /send is not a confirmation. It returns a txHash as soon as the network accepts the transaction. It can still fail on-chain — out of gas, reverted, dropped. Poll /txid until status is success or failed, and treat pending as unfinished.
Common messages
Idempotency
There is none. /send has no idempotency key: the same request sent twice sends funds twice.
Most failures are safe — a 400, 401, 402, 422 or 502 means nothing was ever broadcast, so retrying once you have fixed the cause carries no risk. The dangerous case is a 500, a timeout or a dropped connection: the transaction may have been signed and broadcast before the failure reached you.
Do not resolve that case by checking /transactions and retrying if you don’t find the transfer. EVM history comes from an indexer that lags the mempool, so a fresh broadcast is routinely absent — and transaction rows carry no counterparty address, so you cannot positively identify one transfer anyway. “Not found” does not mean “not sent.”
Reliability sets out the procedure that is actually safe, and lists exactly which failures may be retried automatically.