Bitcoin Transaction Notification Services: Webhook and Alert Platforms

Bitcoin Notification Services Overview

Monitoring Bitcoin addresses for incoming payments requires a reliable notification layer. Whether you are building a payment gateway, an exchange deposit system, or a watch-only wallet, you need to know when a transaction hits the mempool and when it reaches a target number of confirmations. Polling an RPC endpoint in a loop works for prototypes, but production systems need push-based notifications: webhooks, WebSockets, or OS-level callbacks.

The following table compares the major services for Bitcoin transaction notifications. Each approaches the problem differently: BlockCypher offers purpose-built webhook infrastructure, mempool.space provides real-time WebSocket streams, Alchemy wraps Bitcoin node access in its multi-chain platform, GetBlock exposes raw JSON-RPC with optional notification add-ons, and Bitcoin Core's walletnotify gives self-hosted operators direct OS-level callbacks.

For a broader comparison of Bitcoin API providers beyond notification features, see our Bitcoin API comparison and Bitcoin RPC provider comparison.

BlockCypher: Purpose-Built Bitcoin Webhooks

BlockCypher is one of the longest-standing Bitcoin API providers with dedicated webhook infrastructure. Its event system lets you register HTTP callback URLs for specific addresses or transactions and receive POST requests when activity occurs. BlockCypher supports multiple event types: unconfirmed transactions, transaction confirmations at a specified threshold, double-spend attempts, and new block events.

The webhook system allows you to set a confirmation count (e.g., notify at 3 confirmations, or at 6), making it well-suited for payment applications that need to gate actions on confirmation depth. Each webhook fires an HTTP POST with a JSON payload containing the full transaction details. BlockCypher retries failed deliveries automatically.

The free tier allows 200 requests per hour and a limited number of webhook registrations. Paid plans start at $75/month for higher rate limits and more webhook capacity. The main limitation is that BlockCypher's free tier can be restrictive for applications monitoring more than a handful of addresses. For batch address monitoring, you need to register webhooks individually per address or use their payment forwarding feature.

mempool.space: Open-Source WebSocket Streams

mempool.space provides a real-time WebSocket API that streams transaction and block events as they occur. The WebSocket interface supports subscribing to specific addresses and receiving notifications when transactions involving those addresses enter the mempool or confirm in a block. The public instance at mempool.space is free to use with rate limits applied to prevent abuse.

The key advantage of mempool.space is that it is fully open source. You can self-host the entire stack, including the backend, the WebSocket server, and the block explorer frontend, connected to your own Bitcoin Core and Electrum server. Self-hosting eliminates rate limits, removes third-party dependencies, and gives you full control over your notification infrastructure. This makes it a strong fit for privacy-sensitive applications and high-throughput payment systems.

The WebSocket API pushes new block notifications, transaction confirmations, and mempool updates. For tracking specific confirmation counts (e.g., 3-of-6), you would subscribe to new block events and track confirmation depth in your application logic. The public API applies rate limits per IP, and enterprise plans with dedicated infrastructure are available through Mempool Accelerator and their enterprise offering.

Blockstream Esplora: REST API Without Native Push

Blockstream's Esplora API provides a comprehensive REST interface for querying Bitcoin transaction and address data but does not offer native webhook or WebSocket push notifications. To monitor an address for incoming transactions, you must poll the /address/:address/txs endpoint at intervals.

Esplora is open source and powers the block explorer at blockstream.info. Like mempool.space, you can run your own Esplora instance connected to a local Bitcoin Core node for zero-dependency address monitoring. The tradeoff is building your own polling loop and notification dispatch layer on top.

For developers who already use Esplora for UTXO queries and transaction broadcasting, adding a polling-based notification layer is straightforward. But if you need sub-second latency on unconfirmed transactions, a WebSocket or webhook-based service is a better fit.

Alchemy: Multi-Chain Platform With Bitcoin Support

Alchemy added Bitcoin support to its multi-chain infrastructure platform, providing JSON-RPC node access alongside its webhook notification system (Alchemy Notify). The Bitcoin integration supports Custom Webhooks, which can be configured to fire on address activity and mined transactions. The free tier includes 30 million compute units per month and up to 5 active webhooks.

Alchemy's strength is its broader platform ecosystem: if your application already uses Alchemy for Ethereum or Solana, adding Bitcoin monitoring through the same dashboard and API key simplifies your infrastructure. The webhook system includes retry logic, and the dashboard provides delivery logs for debugging.

The limitation for Bitcoin-specific use cases is that Alchemy's Bitcoin support is more recent and less mature than its EVM offerings. Confirmation tracking works through mined transaction events rather than configurable confirmation thresholds, so you need application-side logic to wait for a specific confirmation depth. For Bitcoin-only projects, a dedicated service like BlockCypher or a self-hosted mempool.space instance may offer better depth of integration.

GetBlock: Node Access Without Native Notifications

GetBlock provides shared and dedicated Bitcoin node infrastructure with JSON-RPC access. The free tier offers 40,000 requests per day, and paid plans start at $49/month for shared nodes with higher limits. Dedicated nodes with guaranteed performance are available at higher price points.

GetBlock does not offer native webhook or WebSocket notification services for Bitcoin. To monitor addresses, you would poll Bitcoin RPC methods like getrawmempool and getrawtransaction at intervals. This polling approach works but adds latency compared to push-based systems and consumes request quota proportional to your polling frequency.

GetBlock is best suited as a node backend rather than a notification service. Developers who need both hosted RPC access and push notifications typically pair GetBlock (or a similar provider) with a separate notification layer. See our RPC provider comparison for a detailed breakdown of node-as-a-service pricing and performance.

Bitcoin Core walletnotify and blocknotify: Self-Hosted Callbacks

For operators running their own Bitcoin node, Bitcoin Core provides two built-in notification mechanisms: -walletnotify and -blocknotify. These are command-line options that execute a shell command whenever a relevant event occurs.

-walletnotify="/path/to/script %s %w" fires whenever a transaction affecting a wallet address is received or confirmed. The %s placeholder is replaced with the transaction ID, and %w with the wallet name. Starting with Bitcoin Core 23.0, this callback fires both when a transaction first enters the mempool and again when it confirms in a block, giving you built-in support for tracking unconfirmed and confirmed states.

-blocknotify="/path/to/script %s" fires whenever a new block is connected to the chain, with %s replaced by the block hash. This is useful for triggering confirmation count checks or updating application state on each new block.

The walletnotify approach requires a running full node with the addresses loaded into a descriptor wallet or as watch-only entries. The advantage is zero third-party dependency, zero cost beyond node hardware, and direct access to the raw transaction data via follow-up RPC calls. The disadvantage is operational overhead: you must maintain the node, handle initial block download, manage storage, and ensure uptime yourself.

Pricing and Free Tier Comparison

Cost varies significantly across these services. The following table compares free tier allocations and starting prices for paid plans.

Choosing the Right Notification Approach

The best notification service depends on your application's requirements across four dimensions: latency tolerance, address volume, operational willingness, and cost sensitivity.

For payment applications that need to detect unconfirmed transactions within seconds and track confirmations up to a specific depth, BlockCypher's webhook system or a self-hosted mempool.space instance are the strongest options. Both provide push-based notifications with sub-second latency on mempool events.

For applications monitoring thousands of addresses (exchange deposit systems, custody platforms), running your own Bitcoin Core node with walletnotify scales better than registering thousands of individual webhooks with a hosted provider. Load the addresses into a watch-only wallet, and the node handles monitoring natively with zero per-address cost.

For developers building on multiple chains who want a unified platform, Alchemy offers the convenience of a single dashboard and API key across Bitcoin and other networks. The tradeoff is less granular Bitcoin notification control compared to dedicated Bitcoin services.

For applications building on Spark or other Bitcoin Layer 2 protocols, monitoring the base layer for settlement transactions typically requires combining L2-specific event systems with one of the on-chain notification approaches described here. On-chain notification services track base layer transactions, while L2 protocols handle their own event delivery for off-chain activity.

Implementation Patterns

Regardless of which service you choose, certain architectural patterns apply to any Bitcoin notification system.

Idempotent processing: webhooks can fire more than once for the same event (retries, network issues, service restarts). Store the txid of every processed notification and deduplicate incoming events before taking action.

Confirmation gating: for payment applications, never treat a transaction as final on the first mempool notification. Wait for a minimum number of confirmations appropriate to the payment amount. Low value transactions may accept 1 confirmation, while larger amounts should wait for 3 to 6. See our research on building a Bitcoin payment app for confirmation thresholds by value tier.

Fallback polling: even with push-based notifications, implement a periodic polling check as a safety net. Network partitions, provider outages, or missed webhook deliveries can cause gaps. A background job that reconciles your expected state against the chain every few minutes catches anything the push layer missed.

Fee spike awareness: during periods of high network congestion, unconfirmed transactions may sit in the mempool for hours or days. Your notification handler should account for this by tracking replace-by-fee (RBF) signals and handling transaction replacement gracefully. An unconfirmed notification is not a guarantee that the transaction will confirm.

Frequently Asked Questions

What is the fastest way to get notified of Bitcoin transactions?

WebSocket connections to mempool.space or webhook subscriptions through BlockCypher deliver notifications within seconds of a transaction entering the mempool. For self-hosted setups, Bitcoin Core's walletnotify fires a shell command immediately when the node sees a relevant transaction, typically within 1 to 3 seconds of network propagation.

Can I monitor multiple Bitcoin addresses with a single webhook?

BlockCypher requires registering a separate webhook event for each address you want to monitor, though you can point them all at the same callback URL. mempool.space's WebSocket allows subscribing to multiple addresses on a single connection. Bitcoin Core's walletnotify monitors all addresses in the loaded wallet with a single configuration, making it the most efficient option for bulk address monitoring.

How does Bitcoin Core walletnotify work?

The -walletnotify option in Bitcoin Core executes a shell command whenever a transaction affecting any address in the node's wallet is seen. It fires once when the transaction enters the mempool (unconfirmed) and again when it confirms in a block. The command receives the transaction ID as a parameter, which your script can use to query full transaction details via the JSON-RPC interface.

Do Bitcoin webhook services detect double-spend attempts?

BlockCypher offers a specific "double-spend-tx" event type that fires when it detects a conflicting transaction. Most other services do not provide dedicated double-spend detection. With Bitcoin Core, you can detect conflicts by monitoring for RBF replacements via walletnotify and checking the bip125-replaceable flag on incoming transactions. For payment applications, waiting for at least one confirmation is the most reliable protection against double spends.

Should I use a hosted webhook service or run my own Bitcoin node?

For small-scale monitoring (under a few hundred addresses) or prototyping, hosted services like BlockCypher or Alchemy are faster to set up and require no infrastructure management. For production payment systems monitoring thousands of addresses, running your own Bitcoin Core node with walletnotify or self-hosting mempool.space gives you full control, removes rate limits, eliminates third-party dependencies, and reduces per-address costs to zero. The tradeoff is operational responsibility for node uptime and storage.

How many confirmations should I wait for before considering a Bitcoin payment final?

The standard recommendation is 6 confirmations (roughly 60 minutes) for high-value transactions, which provides strong protection against chain reorganizations. For smaller payments, 1 to 3 confirmations is common in practice. Some services accept zero-confirmation transactions for very low amounts with additional risk checks. The appropriate threshold depends on the transaction value and your application's risk tolerance.

What happens if a webhook delivery fails?

BlockCypher automatically retries failed webhook deliveries. Alchemy retries up to 5 times with exponential backoff. For services without built-in retry (or when using WebSocket connections that may disconnect), your application should implement fallback polling to reconcile missed events. Always design your notification handler to be idempotent so that duplicate deliveries do not cause incorrect behavior.

This tool is for informational purposes only and does not constitute financial advice. Pricing, rate limits, and feature availability change frequently. Always verify current data on each provider's documentation before making infrastructure decisions.