/v1/rpc
The XRP Ledger's own READ commands against MAINNET — the twin of POST /testnet/rpc, so a developer who learned the sandbox changes the prefix and nothing else. Reads only (submitting is POST /submit); the node's in-band error (actNotFound, entryNotFound) rides in result with a 200, as on the node
Request
https://api.xrpl.to/v1/rpc{ method (one of the read commands), params (the command's own fields as an object) }
curl -X POST 'https://api.xrpl.to/v1/rpc'
Response
{ success, took, method, result (the node's own result, verbatim) }
What it does
The XRP Ledger's own READ commands against MAINNET — the twin of POST /testnet/rpc, so a developer who learned the sandbox changes the prefix and nothing else. Reads only (submitting is POST /submit); the node's in-band error (actNotFound, entryNotFound) rides in result with a 200, as on the node
- Notes
- Same list as /testnet/rpc: account_channels, account_currencies, account_info, account_lines, account_nfts, account_objects, account_offers, account_tx, amm_info, book_changes, book_offers, channel_verify, deposit_authorized, feature, fee, gateway_balances, get_aggregate_price, ledger, ledger_closed, ledger_current, ledger_data, ledger_entry, ledger_header, ledger_index, manifest, mpt_holders, nft_buy_offers, nft_history, nft_info, nft_sell_offers, nfts_by_issuer, noripple_check, owner_info, ping, random, ripple_path_find, server_definitions, server_info, server_state, simulate, transaction_entry, tx, tx_history, tx_reduce_relay, vault_info, version. subscribe, unsubscribe and path_find need a session — use the WebSocket