XRPL Webhook FAQ — Common Questions About XRNotify

Frequently Asked Questions About XRPL Webhooks and XRNotify

Whether you are building a wallet tracker, an NFT marketplace, a payment processor, or a DeFi dashboard on the XRP Ledger, you need a reliable way to know when on-chain events happen. XRNotify provides managed webhook infrastructure purpose-built for the XRPL, so you can focus on your application logic instead of blockchain plumbing. Below are the twelve questions we hear most often from developers evaluating and integrating XRNotify.

1. What is a webhook and how does it work?

A webhook is a server-to-server HTTP callback. Instead of your application repeatedly polling an API to check for new data, the data source pushes an HTTP POST request to a URL you control the moment something noteworthy occurs. In the context of the XRP Ledger, XRNotify watches validated ledger transactions in real time and, when a transaction matches your configured filters, immediately delivers a JSON payload to your endpoint. Your server receives the request, verifies the signature header to confirm it came from XRNotify, processes the payload, and returns a 2xx status code to acknowledge receipt. If your server does not acknowledge the delivery, XRNotify automatically retries with exponential backoff. This push-based model eliminates wasted API calls, reduces latency to sub-second levels, and lets you react to on-chain events the instant they are confirmed by the XRPL consensus protocol.

2. What XRPL transaction types does XRNotify support?

XRNotify supports every transaction type defined by the XRP Ledger protocol. This includes the most common types such as Payment, OfferCreate, OfferCancel, TrustSet, and AccountSet, as well as newer and more specialized types like NFTokenMint, NFTokenAcceptOffer, NFTokenCreateOffer, URITokenMint, AMMDeposit, AMMWithdraw, Clawback, and DIDSet. When the XRPL protocol adds new transaction types through amendments, XRNotify adds support shortly after the amendment activates on mainnet. You can subscribe to all transaction types at once or select only the specific types relevant to your use case through the XRNotify dashboard or API. Filtering at the source means your endpoint only receives the events it cares about, reducing noise and processing overhead on your backend.

3. How fast are XRNotify webhook deliveries?

XRNotify delivers webhook notifications with a typical end-to-end latency of under one second from the moment a transaction is validated on the XRP Ledger. The platform maintains persistent connections to multiple XRPL nodes and processes each validated ledger as soon as it closes, which happens roughly every three to five seconds. Once XRNotify detects a matching transaction, it serializes the event payload and dispatches the HTTP POST to your endpoint immediately. The actual network transit time depends on the geographic distance between the XRNotify delivery infrastructure and your server. For endpoints hosted in major cloud regions, you can expect delivery latencies in the range of 200 to 800 milliseconds after ledger validation. XRNotify publishes delivery latency metrics on the status page so you can monitor performance. This sub-second delivery makes XRNotify suitable for latency-sensitive applications like trading bots, real-time portfolio trackers, and instant payment confirmations.

4. What happens if my endpoint is down?

XRNotify implements an automatic retry mechanism with exponential backoff to handle endpoint failures gracefully. When your server returns a non-2xx status code, times out, or is unreachable, XRNotify marks the delivery as failed and schedules a retry. The retry schedule follows exponential backoff intervals: the first retry occurs after approximately 30 seconds, then 1 minute, 5 minutes, 30 minutes, and so on, up to a maximum of 24 hours. XRNotify attempts up to 15 retries per event before marking it as permanently failed. All failed deliveries are logged in your XRNotify dashboard with the HTTP status code, response body, and timestamp, giving you full visibility into what went wrong. If you need to recover events beyond the retry window, XRNotify offers an event replay feature that lets you re-deliver any event from the past seven days on demand. This combination of automatic retries and manual replay ensures you never permanently lose an event.

5. How do I verify that a webhook came from XRNotify?

Every webhook request sent by XRNotify includes an X-XRNotify-Signature header containing an HMAC-SHA256 signature computed over the raw request body using your endpoint-specific signing secret. To verify authenticity, your server should compute the same HMAC-SHA256 hash using the raw body bytes and your signing secret, then compare the result to the value in the signature header using a timing-safe comparison function. If the values match, you can trust that the payload originated from XRNotify and has not been tampered with in transit. Your signing secret is generated when you create an endpoint in the XRNotify dashboard and can be rotated at any time. XRNotify provides verification helper libraries for Node.js, Python, Go, and Ruby, as well as code examples for other languages. Never skip signature verification in production — without it, an attacker could forge webhook payloads and trick your application into processing fabricated transactions.

6. Can I filter events by account address?

Yes, account-based filtering is one of the core capabilities of XRNotify. When you create or update a webhook endpoint, you can specify one or more XRPL account addresses to watch. XRNotify will then deliver only transactions where at least one of your watched addresses appears as the sender, destination, or is otherwise affected by the transaction. You can combine account filters with transaction type filters for precise targeting — for example, you could watch a specific issuer address for only TrustSet transactions, or monitor a hot wallet for Payment events exclusively. Each XRNotify plan supports a different number of watched addresses, ranging from 5 on the free tier to unlimited on the Enterprise plan. Account filters are evaluated server-side inside the XRNotify pipeline, so filtered-out events never consume your delivery quota or generate network traffic to your endpoint. You can update your account filter list at any time through the dashboard or the XRNotify REST API without any downtime.

7. What is the XRNotify event schema format?

XRNotify delivers events as JSON objects with a consistent, well-documented schema. Every event payload includes the following top-level fields: id (a unique UUID for the event), type (the XRPL transaction type such as Payment or NFTokenMint), timestamp (ISO 8601 datetime of when XRNotify processed the event), ledger_index (the validated ledger sequence number), ledger_hash, tx_hash (the transaction hash on the XRPL), and data (an object containing the full transaction metadata and affected nodes). The data field mirrors the structure returned by the XRPL tx method, so if you are already familiar with the XRPL API, the XRNotify payload will feel natural. The schema is versioned via a schema_version field, and XRNotify commits to backward-compatible changes within a major version. Full JSON Schema definitions and example payloads for every transaction type are available in the XRNotify documentation.

8. How does event replay work in XRNotify?

Event replay allows you to re-deliver previously sent webhook events to your endpoint on demand. XRNotify stores every event for a rolling retention window — seven days on the Pro plan and thirty days on the Enterprise plan. You can trigger a replay from the XRNotify dashboard by selecting individual events or by specifying a time range and optional filters. Replayed events are sent to your current endpoint URL with an additional X-XRNotify-Replay: true header so your application can distinguish replays from original deliveries if needed. This feature is invaluable during disaster recovery, when migrating to a new server, or when debugging integration issues. You can also trigger replays programmatically through the XRNotify REST API by posting to the /v1/endpoints/{id}/replay route with a time range and optional event type filter. Replayed events count toward your monthly delivery quota but are not subject to rate limiting, so large batch replays complete quickly. XRNotify processes replay requests asynchronously and delivers events in chronological order.

9. What are the rate limits?

XRNotify enforces rate limits to protect both the platform and your endpoint from overload. On the delivery side, XRNotify sends a maximum of 50 concurrent requests per endpoint. If your server processes webhooks slowly, XRNotify queues additional events and delivers them as in-flight requests complete, maintaining ordering within each account address. On the API side, the XRNotify REST API allows 100 requests per minute for endpoint management operations (create, update, delete, list) and 20 requests per minute for replay operations. These limits apply per API key. If you exceed a rate limit, the API returns a 429 Too Many Requests response with a Retry-After header indicating how many seconds to wait. For most integrations, these limits are more than sufficient. If your application requires higher throughput — for example, monitoring thousands of accounts with high transaction volume — the XRNotify Enterprise plan offers configurable rate limits and dedicated delivery infrastructure tailored to your workload.

10. How much does XRNotify cost?

XRNotify offers a generous free tier and two paid plans designed to scale with your project. The Free plan includes up to 1,000 webhook deliveries per month, 1 endpoint, 5 watched accounts, and community support — ideal for hobby projects and initial prototyping. The Pro plan is aimed at production applications and includes up to 100,000 deliveries per month, 10 endpoints, 100 watched accounts, 7-day event replay, priority email support, and delivery analytics. The Enterprise plan is designed for high-volume and mission-critical deployments and includes unlimited deliveries, unlimited endpoints and watched accounts, 30-day event replay, a dedicated account manager, an SLA with uptime guarantees, custom rate limits, and dedicated infrastructure options. All XRNotify plans include HMAC signature verification, automatic retries with exponential backoff, and access to the full range of XRPL transaction types. Pricing details and a plan comparison table are available at xrnotify.io/pricing. You can upgrade, downgrade, or cancel your XRNotify plan at any time without long-term contracts.

11. Is XRNotify open source?

The XRNotify platform itself is source-available. The core webhook delivery engine, worker infrastructure, and dashboard are maintained in a public GitHub repository under a Business Source License (BSL). This means you can read, audit, and learn from the full XRNotify codebase, submit bug reports, and contribute fixes. However, hosting a competing managed service using the XRNotify code requires a commercial license. In addition to the main platform, XRNotify publishes several fully open-source libraries under the MIT license: the webhook signature verification SDKs for Node.js, Python, Go, and Ruby; a CLI tool for testing webhook endpoints locally; and example integration projects demonstrating common patterns like payment monitoring and NFT tracking. The open-source approach means you are never locked into the XRNotify hosted service — you can inspect exactly how signature verification works, understand the event schema at the code level, and even self-host the platform if your requirements demand it. XRNotify welcomes community contributions through GitHub issues and pull requests.

12. How is XRNotify different from running my own XRPL node?

Running your own XRPL node gives you direct access to the ledger, but it comes with significant operational overhead. A full-history XRPL node requires several terabytes of storage, ongoing disk growth management, regular rippled upgrades, network peering configuration, and monitoring to ensure the node stays synced with the network. You also need to build your own transaction filtering logic, delivery queue, retry mechanism, and observability layer on top of the raw node subscription stream. XRNotify handles all of this for you. The platform maintains redundant connections to multiple geographically distributed XRPL nodes, processes validated ledgers in real time, applies your configured filters, and delivers matching events to your endpoint with automatic retries and signature verification. With XRNotify, there is no infrastructure to provision, no node software to maintain, and no risk of missed events due to node desynchronization. For teams that do run their own node for other reasons, XRNotify can still add value as a secondary notification channel with independent delivery guarantees and built-in replay capabilities that would be complex to replicate from scratch.