Migrate from Horizon to RPC
Applications using Horizon's REST-like API will need to be updated to use the RPC JSON-RPC API when migrating from Horizon to RPC. This guide provides an overview of the key differences between the two APIs and how to migrate your application.
Request / Response Format
Horizon's REST-like API uses HTTP methods and status codes to communicate with clients. Responses are JSON in the HAL format. See Horizon's Response Format.
RPC's JSON-RPC API uses JSON-RPC 2.0 to communicate with clients. Requests to the API are JSON objects that contain one or more method invocations. Responses are also JSON objects that contain a result for each invocation in the request. See JSON-RPC.
Both formats utilise JSON for the overall structure which are relatively simple and do not require any special client code, although there are client SDKs available. Some values contained within are XDR encoded and can be decoded using Stellar SDKs.
Endpoint Mapping
Applications that use the following Horizon endpoints can typically migrate directly to the RPC using the referenced methods.
Endpoints without mappings do not have a direct replacement in the RPC API. To build similar functionality in an application, please consider partnering with an indexer or using the information listed below to build your own indexed representation of horizon endpoints. Consider using other Data products for analytics use cases.
| Horizon Endpoint | Corresponding RPC Method(s) | Indexer Equivalent | Analytics Resources |
|---|---|---|---|
GET / | getLatestLedger getVersionInfo getHealth getNetwork | Not applicable | Analyst Guide |
GET /ledgers | getLedgers | Create a getLedgers with full history, using Galexie, to build a historical ledger view. | Ledgers |
GET /ledgers/{seq} | getLedgers (with filter for sequence) | Use a getLedgers view with full history, filtered by ledger sequence | Ledgers |
GET /ledgers/{seq}/transactions | getTransactions (with filter for ledger sequence) | Use getTransactions with ledger sequence filtering to retrieve transactions for a specific ledger | Transactions |
GET /ledgers/{seq}/operations | getTransactions | Use getTransactions for the given ledger, then parse the transaction's XDR for individual operations. | Operations |
GET /ledgers/{seq}/payments | getEvents getTransactions ⚠️ | Use getEvents (CAP-67 asset events, available since Protocol 23 on nodes that emit classic events) and parse getTransactions meta XDR to tie those events back to individual operations. | Payments |
GET /ledgers/{seq}/effects | getEvents getTransactions ⚠️ | Use getEvents for the effects CAP-67 models (asset movement and trustline authorization), and parse getTransactions meta XDR for every other effect type. | Effects |
POST /transactions | sendTransaction | Not applicable | Not applicable |
POST /transactions_async | sendTransaction | Not applicable | Not applicable |
GET /transactions | getTransactions | Use getTransactions to build a historical transaction list | Transactions |
GET /transactions/{hash} | getTransaction | Use getTransaction to retrieve a specific transaction by its hash | Transactions |
GET /transactions/{hash}/operations | getTransaction | Filter getTransaction by hash and then parse its XDR for operations | Operations |
GET /transactions/{hash}/payments | No direct RPC equivalent; use getEvents or parse getTransactions | Filter getTransaction by hash and analyze its events and operation types to identify payments. | Payments |
GET /transactions/{hash}/effects | No direct RPC equivalent; use getEvents or parse getTransactions | Filter getTransaction by hash and analyze its events and metadata for relevant data. | Effects |
GET /operations | getTransactions | Ingest all historical ledgers/transactions and build and build a view of operations for filtering. | Operations |
GET /operations/{id} | No direct RPC equivalent | Store Horizon's operation ID and map it back to the ledger sequence and transaction index to retrieve the relevant transaction via getTransactions. | Operations |
GET /operations/{id}/effects | No direct RPC equivalent | Retrieve the operation by ID (as above) and then parse its associated transaction and events for effects. | Effects |
GET /fee_stats | getFeeStats simulateTransaction | Indexed data not recommended. | Fee Stats |
GET /accounts | No direct RPC equivalent | Ingest all ledger history via getLedgers to build and maintain a complete list of accounts. | Accounts |
GET /accounts/{address} | getLedgerEntries | Use getLedgerEntries for a specific account address. Note: RPC will not provide trust line information associated with the account directly, as Horizon does. You will need to derive this from ledger entries. | Accounts |
GET /claimable_balances | No direct RPC equivalent | Ingest all ledger history via getLedgers to build and maintain a complete list of claimable balances. | Claimable Balances |
GET /claimable_balances/{id} | getLedgerEntries | Use getLedgerEntries to retrieve a specific claimable balance by ID. | Claimable Balances |
GET /claimable_balances/{id}/transactions | No direct RPC equivalent | Trace transactions that interact with the specific claimable balance ID from their historical ledger data. | Claimable Balances |
GET /claimable_balances/{id}/operations | No direct RPC equivalent | trace operations related to the specific claimable balance ID from your historical ledger data. | Claimable Balances |
GET /liquidity_pools | No direct RPC equivalent | ingest all ledger history via getLedgers to build and maintain a complete list of liquidity pools. | Liquiditity Pools |
GET /liquidity_pools/{id} | getLedgerEntries | Use getLedgerEntries to retrieve a specific liquidity pool by ID. | Liquiditity Pools |
GET /liquidity_pools/{id}/transactions | No direct RPC equivalent | Trace transactions that interact with the specific liquidity pool ID from their historical ledger data. | Liquiditity Pools |
GET /liquidity_pools/{id}/operations | No direct RPC equivalent | Trace operations related to the specific liquidity pool ID from their historical ledger data. | Liquiditity Pools |
GET /liquidity_pools/{id}/effects | No direct RPC equivalent | Trace effects related to the specific liquidity pool ID from their historical ledger data. | Liquiditity Pools |
GET /liquidity_pools/{id}/trades | No direct RPC equivalent | Infer trades related to the specific liquidity pool ID from historical ledger data (e.g., from getEvents and getTransactions metadata). | Liquiditity Pools |
GET /offers | No direct RPC equivalent | Ingest all ledger history via getLedgers to build and maintain a complete list of offers. | Offers |
GET /offers/{id} | getLedgerEntries | Use getLedgerEntries to retrieve a specific offer by ID. | Offers |
GET /offers/{id}/trades | No direct RPC equivalent | Infer trades related to the specific offer ID from historical ledger data (e.g., from getEvents and getTransactions metadata). | Offers |
GET /payments | getEvents getTransactions ⚠️ | Use getEvents (CAP-67 asset events) and process getTransactions metadata for payment-like operations across all history. | Payments |
GET /effects | getEvents getTransactions ⚠️ | Use getEvents for the effects CAP-67 models, and process getTransactions metadata to derive the remaining effect types across all history. | Effects |
GET /trades | getEvents getTransactions ⚠️ | Infer trades from getEvents and getTransactions metadata across all history, as there is no direct "trade event" in RPC. | Trades |
The getTransactions method can be used to retrieve events batched by transaction. The events are contained in the meta XDR of the transaction (field resultMetaXdr).
The getEvents method is not a direct replacement for Horizon's endpoints.
Since CAP-67 shipped in Protocol 23, the method can return events from classic operations as well as from contracts. Those unified asset events are emitted as transfer, mint, burn, clawback, fee, and set_authorized, so a single stream can cover the movement of assets and changes to trustline authorization.
Classic events are not on by default. They are only present if the Stellar Core instance backing the RPC runs with EMIT_CLASSIC_EVENTS=true, and covering ledgers from Protocol 22 and earlier also requires BACKFILL_STELLAR_ASSET_EVENTS=true. If you run your own RPC, set both before relying on this mapping. If you use a provider, confirm with them. See Events for more detail.
That is still narrower than Horizon's effects. Anything CAP-67 does not model, such as signer updates, data entry changes, sequence number bumps, and offer management, has to come from the meta XDR of the transaction. The getTransactions method returns that meta XDR (field resultMetaXdr), which also contains events from contracts.