One REST API for every network
Create wallets, issue deposit addresses, send payouts and read balances with plain HTTPS requests. Start free in the sandbox, then move to mainnet once your company is verified.
Three steps to a working wallet
Get a sandbox API key
Sign up and issue a test-network key from the dashboard. Sandbox keys are available before company verification, so you can start building straight away.
Dashboard > API keysCreate a wallet
Create an entity for each customer or account, then request a deposit address on any supported asset. Your users never handle a seed phrase.
POST /v1/entitiesSend a transfer
Ask for a payout with an idempotency key. Tetlith checks it against your withdrawal policy, sends it, tracks confirmations and sends a webhook when it completes or fails.
POST /v1/transactionsEverything you need, over HTTPS
JSON requests, resource-based endpoints and asset codes such as USDC_ETH or USDT_TRON. Amounts are sent as strings in the asset's smallest unit, so nothing is lost to rounding.
Browse the API reference01POST /v1/entities02{ "externalId": "cus_4821", "assets": ["USDC_ETH"] }0304POST /v1/entities/:id/addresses05{ "asset": "USDC_ETH" }0607POST /v1/transactions08{ "fromEntityId": "...", "asset": "USDC_ETH",09 "amount": "250000000", "toAddress": "0x...",10 "idempotencyKey": "payout-1042" }1112// webhook: withdrawal.finalised, deposit.confirmed
Wallets
Create an entity for each customer, account or team. It holds their balances on every supported network.
POST /v1/entitiesDeposit addresses
Issue a deposit address per customer and asset. Incoming payments are detected and attributed to that customer.
POST /v1/entities/:id/addressesTransactions and payouts
Send to external addresses or between entities, under the limits and approved destinations you set per asset.
POST /v1/transactionsGET /v1/transactionsBalances
Read each customer's balance per asset, including amounts on their way in or out.
GET /v1/entities/:id/holdingsScoped API keys
Each key carries only the scopes you grant. Read access such as ledger:read is separate from money-moving scopes such as transfer:create, withdrawal:create and treasury:spend.
Signed webhooks
Every delivery is signed so you can check it came from Tetlith, and retried automatically if your endpoint does not acknowledge it.
deposit.sighteddeposit.confirmeddeposit.reorgedwithdrawal.finalisedwithdrawal.failedreconciliation.driftProve it before you commit to it
The sandbox is the same API on test networks, free to use while you build. Test-network keys are issued before company verification, and mainnet keys follow once verification passes.
Talk to our teamThe rules that keep production quiet
Safe to retry
Every request that moves money takes an idempotency key you choose. Send the same key twice and you get the first result back, never a second transaction. Retry freely after a timeout.
Told, not polled
You do not have to watch the chain. A signed webhook tells you when a deposit arrives, when a payout completes and when one fails, and deliveries are retried automatically if your endpoint does not acknowledge them.
Keys that do less
Reading balances and moving funds are separate scopes. A read-only key cannot be turned into one that can spend, so give each service only the access it needs.
The sandbox is real
It is the same API on test networks, with the same requests, responses and webhooks. When your company verification passes, you switch to mainnet keys.