BitcoinDatabase.com

Query the chain · Webhook API

Bitcoin webhook API for transaction and address notifications

A Bitcoin webhook API tells your app the moment something happens on-chain instead of making you poll for it. Watch an address and get a callback when it receives a payment, when a transaction it sent gets its first confirmation, or when it reaches the confirmation depth you require. BitcoinDatabase tracks the chain tip block by block and posts a JSON payload to your endpoint within seconds of the event, so payment flows, deposit crediting and monitoring dashboards react in real time.

or try it below ↓

REST API · SQL · dashboards · address history from genesis

Query Console
btc
try:

Hit Run to query the Bitcoin blockchain.

Live from the chain for .

BTC

Balance trail

informational on-chain data · not financial advice

REST API · SQL · dashboards, one indexed dataset. Reading the chain ...

You register the addresses or transaction IDs you care about, set the confirmation threshold that matters for your risk model, and we handle the rest: retries on failure, signed payloads you can verify, and the same event history queryable over REST if you miss one. No node to run, no mempool to watch yourself. This is informational on-chain data only, not financial or investment advice.

REST API SQL DASHBOARDS WEBHOOKS CSV EXPORT

History from genesis queryable in seconds

On-chain data not financial advice

Why it works

What you get with Webhook API

Events, not polling

Register an address or transaction and receive a callback the instant it sees activity or reaches your confirmation threshold, so you stop hammering an endpoint on a timer.

Confirmation-aware

Fire at zero-conf for fast UX or wait for the depth your risk model needs. You choose the threshold per subscription, from mempool sighting to six confirmations.

Reliable delivery

Payloads are signed so you can verify them, delivery retries on failure, and every event stays queryable over REST so a missed webhook is never lost data.

What it handles

The indexed Bitcoin chain, queryable your way

Look up an address, a transaction, a UTXO, the rich list or an on-chain metric, by REST API, SQL or dashboard. The same authoritative data, reconciled block-by-block against the canonical chain, without running a node.

  • Get notified when a watched address receives BTC
  • Trigger on first confirmation or a custom depth
  • Credit deposits and reconcile payments automatically
  • Verify signed payloads and replay missed events over REST
  • Monitor thousands of addresses without running a node
GET /v1/address/{addr} query result
200 · JSON
{
  "address": "bc1qxy2k…l0wdv8",
  "balance_btc": 68432.10,
  "balance_usd": 4612165420,
  "tx_count": 1284,
  "unspent_outputs": 37,
  "first_seen": "2014-02-09"
}
indexed from genesis · to the satoshi ✓ reconciled block-by-block

Why BitcoinDatabase

One platform, queryable three ways

Not a raw node to sync, not an indexer to build, and not five vendors to stitch together. The fully-indexed Bitcoin blockchain, available as a REST API, as SQL, and as dashboards, on one authoritative dataset.

REST API

Typed JSON for addresses, transactions, balances, UTXOs and metrics. Drop it into apps, wallets, explorers and agents with curl, Python or any HTTP client.

SQL access

Run SQL directly against the indexed Bitcoin dataset for ad-hoc analysis, cohorts and exports, the same data the API and dashboards read from.

Compliance-first

Informational on-chain data and analytics only. Entity labels and flow tracing are framed as tooling to support a regulated team's own review, not accusations.

Good questions

Questions about Webhook API

We track the chain tip block by block, so a callback typically reaches your endpoint within seconds of the triggering event, whether that is a mempool sighting or a confirmation at the depth you set. Delivery retries on failure and every event stays queryable over REST as a backstop.
Yes. You can subscribe thousands of addresses and transaction IDs to webhooks and set a confirmation threshold per subscription. That is common for exchanges and payment processors crediting deposits. This is informational on-chain data only, not financial advice.
It is a service that pushes you a signed HTTP request the moment an address or transaction you subscribed to sees activity, instead of you polling an endpoint on a timer. BitcoinDatabase posts to your URL on new activity and again as confirmation counts change, and every delivery carries an X-Bdb-Signature header so you can verify it came from us before you ingest anything.
No, and this is the main reason teams use a webhook API. Getting notifications from your own node means running Bitcoin Core, keeping it synced, wiring up ZeroMQ or wallet notify scripts, and then building the address index Core does not keep. We measured what a managed node can answer and it cannot resolve an address at all, so even renting one leaves you building the index yourself.
Check the signature before you trust the body. Each delivery includes an X-Bdb-Signature header computed over the payload with your key, so you recompute it on your side and compare. Treat any request that fails that check as hostile and drop it. Webhook URLs are effectively public once they exist, so signature verification is what separates a real event from anyone who guessed your endpoint.
Deliveries are retried rather than dropped, which is why an events pipeline needs to be idempotent on your side. Key your handler on the transaction id plus the confirmation depth so that receiving the same event twice is harmless. The common production bug is not a missed webhook, it is a duplicate one processed as if it were new.
Only for user interface feedback, never for releasing value. A zero-confirmation event tells you a transaction is in the mempool, which is genuine information and worth showing as pending, but it can still be replaced or simply never mined. Wait for the confirmation depth your risk tolerance calls for before you credit an account or ship a product.
Enough that the practical limit is your own ingestion, not the subscription list. Exchange and custody teams routinely watch large deposit address sets this way. If you are watching an xpub rather than individual addresses, remember the gap limit: scanners stop after roughly 20 consecutive unused derived addresses, so a wallet that jumped ahead in its derivation path can hide funds from a naive watcher.
Yes, and that is usually the event that matters. The first delivery tells you something arrived; the later ones tell you it is safe. Because the confirmation count changes as blocks land, you get a sequence of deliveries per transaction rather than one, so store the depth you have already acted on and ignore anything at or below it.

Explore more

More ways to query Bitcoin with BitcoinDatabase

Stop running a node. Just query Bitcoin.

Run your first query now and get on-chain data back by REST API, SQL or dashboard, with address history back to the genesis block over REST. Informational on-chain data only, not financial advice.

See pricing

History from genesis over REST · SQL · dashboards · addresses, transactions, UTXOs, metrics