Detect an Incoming Deposit
You need to know the moment a user funds their address. This guide detects deposits either by polling the deposits endpoint or by receiving a webhook, so you can credit balances as soon as a transfer confirms. Works across eth, btc and tron.
- Derived deposit addresses registered under a wallet.
- An API key, and a webhook URL if you prefer push over poll.
1Poll for deposits on an address
Call GET /v1/deposits/{chain} with the address. The response lists deposits with confirmation counts.
curl "https://api.1st-node.com/v1/deposits/tron?address=TQ1n7..." \
-H "Authorization: Bearer sk_live_..."
> {"deposits":[{"hash":"7c9f...","amount":"5000000",
> "confirmations":19,"asset":"USDT"}]}2Or subscribe to a webhook
Register a webhook so deposits are pushed as they confirm. Verify the signature, then credit the user idempotently on hash.
> POST https://your-app.com/hooks/deposit
> {"chain":"tron","address":"TQ1n7...","hash":"7c9f...",
> "amount":"5000000","confirmations":19,"asset":"USDT"}3Wait for enough confirmations
Credit only after your required confirmation threshold. Track each hash idempotently so a re-delivered webhook does not double-credit.
Frequently asked
Poll or webhook — which should I use?
Webhooks push deposits as they confirm and scale better; polling GET /v1/deposits is fine for low volume or reconciliation. Both key on the transaction hash.
How do I avoid double-crediting?
Treat the transaction hash as an idempotency key and credit once past your confirmation threshold. Re-delivered webhooks carry the same hash.
Keep reading
Top up, get a key, ship.
Self-serve. Pay in crypto or card. Metered by credits — heavy primitives cost more, simple ones are cheap.
Get API key