Definition and scope
XRPL JSON-RPC vs. WebSocket APIs addresses a distinct part of developer guides. Choose request-response HTTP access or a persistent connection with subscriptions.
Reliable XRPL applications do more than submit JSON. They choose appropriate server connections, manage pagination and subscriptions, construct and sign transactions safely, interpret tentative and validated results, and recover cleanly from interruption. Applications must preserve exact amounts, protect signing material, handle retries idempotently, and reconcile against validated ledgers.
How it works
JSON-RPC over HTTP uses discrete request-response calls, while WebSocket keeps a bidirectional connection and supports both requests and subscriptions. Method payloads are similar, but connection lifecycle and event delivery differ.
- JSON-RPC: verify this field, object, or component against the cited protocol documentation.
- WebSocket: verify this field, object, or component against the cited protocol documentation.
- subscribe: verify this field, object, or component against the cited protocol documentation.
- request ID: verify this field, object, or component against the cited protocol documentation.
Comparison at a glance
Use these dimensions to choose between the concepts without treating their names as interchangeable.
| Dimension | HTTP JSON-RPC | WebSocket |
|---|---|---|
| Connection | Request then response | Persistent bidirectional connection |
| Subscriptions | No | Yes |
| Good fit | Occasional reads and simple infrastructure | Live ledger or account events |
| Recovery concern | Polling interval and retries | Reconnect and missed-event gaps |
Practical example and checks
Use HTTP for occasional account_info queries and WebSocket subscribe for continuous validated-ledger or account events, with reconnect and gap-recovery logic around the stream.
For production use, preserve the exact signed or queried data, record the network and validated ledger reference, and compare the result with the current primary documentation before changing off-ledger state.
Open the related live demo or evidence lab →Limits, risks, and common confusion
WebSocket delivery is not durable messaging, and HTTP polling is not inherently stale if designed correctly. Both depend on server trust, limits, and validated-state checks.
Applications must preserve exact amounts, protect signing material, handle retries idempotently, and reconcile against validated ledgers.
Current network status
Network-independent guidance. This guide explains an operational or representational concept. Confirm live server values and service-specific behavior before relying on it in production.
Status reviewed 2026-08-23. Amendment-dependent behavior must be rechecked against the network's live feature state before operational use.