This change cleans up the `API-CHANGELOG.md` file. It moves the version-specific documentation to other files and fleshes out the changelog with all the API-related changes in each version.
18 KiB
API Changelog
This changelog is intended to list all updates to the public API methods.
For info about how API versioning works, including examples, please view the XLS-22d spec. For details about the implementation of API versioning, view the implementation PR. API versioning ensures existing integrations and users continue to receive existing behavior, while those that request a higher API version will experience new behavior.
The API version controls the API behavior you see. This includes what properties you see in responses, what parameters you're permitted to send in requests, and so on. You specify the API version in each of your requests. When a breaking change is introduced to the rippled API, a new version is released. To avoid breaking your code, you should set (or increase) your version when you're ready to upgrade.
The commandline always uses the latest API version. The command line is intended for ad-hoc usage by humans, not programs or automated scripts. The command line is not meant for use in production code.
For a log of breaking changes, see the API Version [number] headings. In general, breaking changes are associated with a particular API Version number. For non-breaking changes, scroll to the XRP Ledger version [x.y.z] headings. Non-breaking changes are associated with a particular XRP Ledger (rippled) release.
API Version 3 (Beta)
API version 3 is currently a beta API. It requires enabling [beta_rpc_api] in the rippled configuration to use. See API-VERSION-3.md for the full list of changes in API version 3.
API Version 2
API version 2 is available in rippled version 2.0.0 and later. See API-VERSION-2.md for the full list of changes in API version 2.
API Version 1
This version is supported by all rippled versions. For WebSocket and HTTP JSON-RPC requests, it is currently the default API version used when no api_version is specified.
XRP Ledger server version 3.1.0
Version 3.1.0 was released on Jan 27, 2026.
Additions in 3.1.0
vault_info: New RPC method to retrieve information about a specific vault (part of XLS-66 Lending Protocol). (#6156)
XRP Ledger server version 3.0.0
Version 3.0.0 was released on Dec 9, 2025.
Additions in 3.0.0
ledger_entry: Supports all ledger entry types with dedicated parsers. (#5237)ledger_entry: New error codesentryNotFoundandunexpectedLedgerTypefor more specific error handling. (#5237)ledger_entry: Improved error messages with more context (e.g., specifying which field is invalid or missing). (#5237)ledger_entry: Assorted bug fixes in RPC processing. (#5237)simulate: Supports additional metadata in the response. (#5754)
XRP Ledger server version 2.6.2
Version 2.6.2 was released on Nov 19, 2025.
This release contains bug fixes only and no API changes.
XRP Ledger server version 2.6.1
Version 2.6.1 was released on Sep 30, 2025.
This release contains bug fixes only and no API changes.
XRP Ledger server version 2.6.0
Version 2.6.0 was released on Aug 27, 2025.
Additions in 2.6.0
account_info: AddedallowTrustLineLockingflag in response. (#5525)ledger: Removed the type filter from the RPC command. (#4934)subscribe(validationsstream):network_idis now included. (#5579)subscribe(transactionsstream):nftoken_id,nftoken_ids, andoffer_idare now included in transaction metadata. (#5230)
XRP Ledger server version 2.5.1
Version 2.5.1 was released on Sep 17, 2025.
This release contains bug fixes only and no API changes.
XRP Ledger server version 2.5.0
Version 2.5.0 was released on Jun 24, 2025.
Additions and bugfixes in 2.5.0
tx: Addedctidfield to the response and improved error handling. (#4738)ledger_entry: Improved error messages inpermissioned_domain. (#5344)simulate: Improved multi-sign usage. (#5479)channel_authorize: Ifsigning_supportis not enabled in the config, the RPC is disabled. (#5385)subscribe(admin): Removed webhook queue limit to prevent dropping notifications; reduced HTTP timeout from 10 minutes to 30 seconds. (#5163)ledger_data(gRPC): Fixed crashing issue with some invalid markers. (#5137)account_lines: Fixed error withno_rippleandno_ripple_peersometimes showing up incorrectly. (#5345)account_tx: Fixed issue with incorrect CTIDs. (#5408)
XRP Ledger server version 2.4.0
Version 2.4.0 was released on March 4, 2025.
Additions and bugfixes in 2.4.0
simulate: A new RPC that executes a dry run of a transaction submission. (#5069)- Signing methods (
sign,sign_for,submit): Autofill fees better, properly handle transactions without a base fee, and autofill theNetworkIDfield. (#5069) ledger_entry:stateis added as an alias forripple_state. (#5199)ledger,ledger_data,account_objects: Support filtering ledger entry types by their canonical names (case-insensitive). (#5271)validators: Added new fieldvalidator_list_thresholdin response. (#5112)server_info: Added git commit hash info on admin connection. (#5225)server_definitions: Changed largerUIntserialized types toHash. (#5231)
XRP Ledger server version 2.3.1
Version 2.3.1 was released on Jan 29, 2025.
This release contains bug fixes only and no API changes.
XRP Ledger server version 2.3.0
Version 2.3.0 was released on Nov 25, 2024.
Breaking changes in 2.3.0
book_changes: If the requested ledger version is not available on this node, aledgerNotFounderror is returned and the node does not attempt to acquire the ledger from the p2p network (as with other non-admin RPCs). Admins can still attempt to retrieve old ledgers with theledger_requestRPC.
Additions and bugfixes in 2.3.0
book_changes: Returns avalidatedfield in its response. (#5096)book_changes: Accepts shortcut strings (current,closed,validated) for theledger_indexparameter. (#5096)server_definitions: Includeindexin response. (#5190)account_nfts: Fix issue where unassociated marker would return incorrect results. (#5045)account_objects: Fix issue where invalid marker would not return an error. (#5046)account_objects: Disallow filtering by ledger entry types that an account cannot hold. (#5056)tx: Allow lowercase CTID. (#5049)feature: Better error handling for invalid values offeature. (#5063)
XRP Ledger server version 2.2.0
Version 2.2.0 was released on Jun 5, 2024. The following additions are non-breaking (because they are purely additive):
feature: Add a non-admin mode for users. (It was previously only available to admin connections.) The method returns an updated list of amendments, including their names and other information. (#4781)
XRP Ledger server version 2.0.1
Version 2.0.1 was released on Jan 29, 2024. The following additions are non-breaking:
path_find: Fixes unbounded memory growth. (#4822)
XRP Ledger server version 2.0.0
Version 2.0.0 was released on Jan 9, 2024. The following additions are non-breaking (because they are purely additive):
server_definitions: A new RPC that generates adefinitions.json-like output that can be used in XRPL libraries.- In
Paymenttransactions,DeliverMaxhas been added. This is a replacement for theAmountfield, which should not be used. Typically, thedelivered_amount(in transaction metadata) should be used. To ease the transition,DeliverMaxis present regardless of API version, since adding a field is non-breaking. - API version 2 has been moved from beta to supported, meaning that it is generally available (regardless of the
beta_rpc_apisetting). The full list of changes is in API-VERSION-2.md.
XRP Ledger server version 1.12.0
Version 1.12.0 was released on Sep 6, 2023. The following additions are non-breaking (because they are purely additive):
server_info: Addedports, an array which advertises the RPC and WebSocket ports. This information is also included in the/crawlendpoint (which callsserver_infointernally).grpcandpeerports are also included. (#4427)portscontains objects, each containing aportfor the listening port (a number string), and aprotocolarray listing the supported protocols on that port.- This allows crawlers to build a more detailed topology without needing to port-scan nodes.
- (For peers and other non-admin clients, the info about admin ports is excluded.)
- Clawback: The following additions are gated by the Clawback amendment (
featureClawback). (#4553)- Adds an AccountRoot flag called
lsfAllowTrustLineClawback. (#4617)- Adds the corresponding
asfAllowTrustLineClawbackAccountSet Flag as well. - Clawback is disabled by default, so if an issuer desires the ability to claw back funds, they must use an
AccountSettransaction to set the AllowTrustLineClawback flag. They must do this before creating any trust lines, offers, escrows, payment channels, or checks.
- Adds the corresponding
- Adds the Clawback transaction type, containing these fields:
Account: The issuer of the asset being clawed back. Must also be the sender of the transaction.Amount: The amount being clawed back, with theAmount.issuerbeing the token holder's address.
- Adds an AccountRoot flag called
- Adds AMM (#4294, #4626) feature:
- Adds
amm_infoAPI to retrieve AMM information for a given tokens pair. - Adds
AMMCreatetransaction type to createAMMinstance. - Adds
AMMDeposittransaction type to deposit funds intoAMMinstance. - Adds
AMMWithdrawtransaction type to withdraw funds fromAMMinstance. - Adds
AMMVotetransaction type to vote for the trading fee ofAMMinstance. - Adds
AMMBidtransaction type to bid for the Auction Slot ofAMMinstance. - Adds
AMMDeletetransaction type to deleteAMMinstance. - Adds
sfAMMIDtoAccountRootto indicate that the account isAMM's account.AMMIDis used to fetchltAMM. - Adds
lsfAMMNodeTrustLineflag to indicate that one side of theTrustLineisAMMaccount. - Adds
tfLPToken,tfSingleAsset,tfTwoAsset,tfOneAssetLPToken,tfLimitLPToken,tfTwoAssetIfEmpty,tfWithdrawAll,tfOneAssetWithdrawAllwhich allow a trader to specify different fields combination forAMMDepositandAMMWithdrawtransactions. - Adds new transaction result codes:
- tecUNFUNDED_AMM: insufficient balance to fund AMM. The account does not have funds for liquidity provision.
- tecAMM_BALANCE: AMM has invalid balance. Calculated balances greater than the current pool balances.
- tecAMM_FAILED: AMM transaction failed. Fails due to a processing failure.
- tecAMM_INVALID_TOKENS: AMM invalid LP tokens. Invalid input values, format, or calculated values.
- tecAMM_EMPTY: AMM is in empty state. Transaction requires AMM in non-empty state (LP tokens > 0).
- tecAMM_NOT_EMPTY: AMM is not in empty state. Transaction requires AMM in empty state (LP tokens == 0).
- tecAMM_ACCOUNT: AMM account. Clawback of AMM account.
- tecINCOMPLETE: Some work was completed, but more submissions required to finish. AMMDelete partially deletes the trustlines.
- Adds
XRP Ledger server version 1.11.0
Version 1.11.0 was released on Jun 20, 2023.
Breaking changes in 1.11
- Added the ability to mark amendments as obsolete. For the
featureadmin API, there is a new possible value for thevetoedfield. (#4291)- The value of
vetoedcan now betrue,false, or"Obsolete".
- The value of
- Removed the acceptance of seeds or public keys in place of account addresses. (#4404)
- This simplifies the API and encourages better security practices (i.e. seeds should never be sent over the network).
- For the
ledger_datamethod, when all entries are filtered out, thestatefield of the response is now an empty list (in other words, an empty array,[]). (Previously, it would returnnull.) While this is technically a breaking change, the new behavior is consistent with the documentation, so this is considered only a bug fix. (#4398) - If and when the
fixNFTokenRemintamendment activates, there will be a new AccountRoot field,FirstNFTSequence. This field is set to the current account sequence when the account issues their first NFT. If an account has not issued any NFTs, then the field is not set. (#4406)- There is a new account deletion restriction: an account can only be deleted if
FirstNFTSequence+MintedNFTokens+256is less than the current ledger sequence. - This is potentially a breaking change if clients have logic for determining whether an account can be deleted.
- There is a new account deletion restriction: an account can only be deleted if
- NetworkID
- For sidechains and networks with a network ID greater than 1024, there is a new transaction common field,
NetworkID. (#4370)- This field helps to prevent replay attacks and is now required for chains whose network ID is 1025 or higher.
- The field must be omitted for Mainnet, so there is no change for Mainnet users.
- There are three new local error codes:
telNETWORK_ID_MAKES_TX_NON_CANONICAL: aNetworkIDis present but the chain's network ID is less than 1025. Remove the field from the transaction, and try again.telREQUIRES_NETWORK_ID: aNetworkIDis required, but is not present. Add the field to the transaction, and try again.telWRONG_NETWORK: aNetworkIDis specified, but it is for a different network. Submit the transaction to a different server which is connected to the correct network.
- For sidechains and networks with a network ID greater than 1024, there is a new transaction common field,
Additions and bug fixes in 1.11
- Added
nftoken_id,nftoken_idsandoffer_idmeta fields into NFTtxandaccount_txresponses. (#4447) - Added an
account_flagsobject to theaccount_infomethod response. (#4459) - Added
NFTokenPagesto theaccount_objectsRPC. (#4352) - Fixed:
markerreturned from theaccount_linescommand would not work on subsequent commands. (#4361)
XRP Ledger server version 1.10.0
Version 1.10.0 was released on Mar 14, 2023.
Breaking changes in 1.10
- If the
XRPFeesfeature is enabled, thefee_reffield will be removed from the ledger subscription stream, because it will no longer have any meaning.
Unit tests for API changes
The following information is useful to developers contributing to this project:
The purpose of unit tests is to catch bugs and prevent regressions. In general, it often makes sense to create a test function when there is a breaking change to the API. For APIs that have changed in a new API version, the tests should be modified so that both the prior version and the new version are properly tested.
To take one example: for account_info version 1, WebSocket and JSON-RPC behavior should be tested. The latest API version, i.e. API version 2, should be tested over WebSocket, JSON-RPC, and command line.