A public XRPL RPC endpoint
Built by XRPL Labs, with a decade of operating XRPL at scale.
This URL answers the same API a native node does. It serves that API over four transports: JSON-RPC over HTTP POST, one command per HTTP GET route, WebSocket with subscriptions, and Server-Sent Events. Server-Sent Events is a GET that stays open. It streams the subscription feeds as they happen.
This page is what a browser gets. Every other client gets the JSON service descriptor. That covers curl, an SDK, and any fetch that does not ask for text/html. Operational health is at /health.
No key is needed for any of it. A key only raises your rate limits. If you have been given one, using an API key at the foot of this page shows every way this endpoint accepts one. There is an example for each transport.
Live network stats
Four ways to call it
Native API. Your choice of transport.
Try it
Compose a request. See the response in real time.
Pick a command and send it.
No response yet.
Commands
Every command available on this network.
proxy answered by this endpoint, not a rippled or xahaud command. A native node answers unknownCmd.
No matching commands. Try a different search.
This list comes from this deployment's command registry. It shows what this endpoint serves on this network, and which transports each command is reachable over.
Using an API key
The same public endpoint, with higher rate limits.
A key buys a higher rate limit, and nothing else. Public access is subject to fair use. Every command works without a key, and you never need one to read from this network. A key raises the rate limits on the calls you make with it, on all four transports. Your rate limit is a set of quotas, each over its own time window. Whichever one you reach first is the one that holds you. A short window can hold you while a longer one still looks healthy. Every HTTP answer tells you the quota that is binding you, what is left of it, and how many seconds until it starts over.
Keys are issued on request. You can buy one commercially, or ask for a grant under special circumstances. Use the contact address in the banner at the top of this page.
Keep your key on your own backend. Never ship it to a device!
A key belongs on a server you control. It must never reach a browser, a mobile app, a desktop app, or anywhere a stranger can read it. Not in JavaScript. Not in a URL a page requests. Not in a repository. Anything you ship to a device can be read from that device.
If your key leaks, strangers make calls with it. The rate limit you paid for gets exhausted, and your own calls are the ones refused.
Route your calls through your own backend and keep the key there.
Special behaviour
The details that matter when you go to production.
Which quota is binding you
headersEvery HTTP answer tells you the quota that is binding you. The names are RateLimit-Limit (that quota), RateLimit-Remaining (what is left of it in this window), RateLimit-Reset (seconds until that window starts over), RateLimit-Policy (every tier you are held to), and RateLimit-Identity (how you were judged: an API key, or an address). A short window can hold you while a longer one still looks healthy. Whichever you reach first is the one that holds you.
Realtime quota information
commandWebSocket sees those headers once, on the 101. After that, send the quota command (the same name on POST and GET) and this endpoint answers every tier of your allowance. A native node answers unknownCmd for that name.
Is the endpoint serving
endpoint/health is the operational probe. It is JSON, not this page. Use it to see whether the endpoint is serving, not to read the chain.
Wait for a ledger just ahead of the tip
behaviourWhen you request a ledger that is almost within reach, a few closes ahead of the tip, this endpoint holds the response briefly and sends it when that ledger comes in (up to three closes ahead by default). It was not slow. The ledger was slightly in the future, and the wait is there so the answer arrives from a node that has it.
Almost every client wants that. It covers the race where one node has just closed a ledger and another sees it a few hundred milliseconds later.
Opt out of the ledger wait
propertyIf you really do not want the wait, add "nodelay": true to the command (GET, POST, or WebSocket). The proxy then answers immediately. If no node has the ledger yet, that answer is lgrNotFound, the same result the wait would have produced.
Default blacklist protection
behaviourThis endpoint refuses a submit or submit_multisigned whose decoded transaction names a blacklisted account, ledger object, or NFT / URIToken. The answer is a submit response with engine_result telBLACKLISTED, a local tel* failure, not a JSON-RPC error. The submit is still logged here as prevented.
Opt out of default blacklist protection
propertyIf you really do need to send a blacklisted transaction, add "force": true to the command (POST or WebSocket). The flag is stripped before a backend sees it, the same way nodelay is.
