mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-22 04:35:49 +00:00
Migrate old callout syntax
This commit is contained in:
mDuo13
@@ -165,7 +165,7 @@ The response follows the [standard format][], with a successful result containin
|
||||
| `send_currencies` | Array of Strings | Array of [Currency Code][]s for currencies that this account can send. |
|
||||
| `validated` | Boolean | If `true`, this data comes from a validated ledger. |
|
||||
|
||||
**Note:** The currencies that an account can send or receive are defined based on a check of its trust lines. If an account has a trust line for a currency and enough room to increase its balance, it can receive that currency. If the trust line's balance can go down, the account can send that currency. This method _doesn't_ check whether the trust line is [frozen](../../../../concepts/tokens/fungible-tokens/freezes.md) or authorized.
|
||||
{% admonition type="info" name="Note" %}The currencies that an account can send or receive are defined based on a check of its trust lines. If an account has a trust line for a currency and enough room to increase its balance, it can receive that currency. If the trust line's balance can go down, the account can send that currency. This method _doesn't_ check whether the trust line is [frozen](../../../../concepts/tokens/fungible-tokens/freezes.md) or authorized.{% /admonition %}
|
||||
|
||||
## Possible Errors
|
||||
|
||||
|
||||
@@ -84,7 +84,7 @@ The request includes the following parameters:
|
||||
| `marker` | [Marker][] | No | Value from a previous paginated response. Resume retrieving data where that response left off. |
|
||||
| `type` | String | No | Filter results by a ledger entry type. The valid types are: `bridge`, `check`, `deposit_preauth`, `escrow`, `nft_offer`, `nft_page`, `offer`, `payment_channel`, `signer_list`, `state` (trust line), and `ticket`. <!-- Author's note: Omitted types that can't be owned by an account --> |
|
||||
|
||||
**Note:** The commandline interface to the `account_objects` command doesn't accept the `type` field. Use the [json method][] to send the JSON-RPC format request on the commandline instead.
|
||||
{% admonition type="info" name="Note" %}The commandline interface to the `account_objects` command doesn't accept the `type` field. Use the [json method][] to send the JSON-RPC format request on the commandline instead.{% /admonition %}
|
||||
|
||||
## Response Format
|
||||
|
||||
|
||||
@@ -441,7 +441,7 @@ The response follows the [standard format][], with a successful result containin
|
||||
| `transactions` | Array | Array of transactions matching the request's criteria, as explained below. |
|
||||
| `validated` | Boolean | If included and set to `true`, the information in this response comes from a validated ledger version. Otherwise, the information is subject to change. |
|
||||
|
||||
**Note:** The server may respond with different values of `ledger_index_min` and `ledger_index_max` than you provided in the request, for example if it did not have the versions you specified on hand.
|
||||
{% admonition type="info" name="Note" %}The server may respond with different values of `ledger_index_min` and `ledger_index_max` than you provided in the request, for example if it did not have the versions you specified on hand.{% /admonition %}
|
||||
|
||||
Each transaction object includes the following fields, depending on whether it was requested in JSON or hex string (`"binary":true`) format.
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ labels:
|
||||
|
||||
The `gateway_balances` command calculates the total balances issued by a given account, optionally excluding amounts held by [operational addresses](../../../../concepts/accounts/account-types.md).
|
||||
|
||||
**Caution:** Some public servers disable this API method because it can require a large amount of processing.
|
||||
{% admonition type="warning" name="Caution" %}Some public servers disable this API method because it can require a large amount of processing.{% /admonition %}
|
||||
|
||||
## Request Format
|
||||
An example of the request format:
|
||||
|
||||
@@ -12,7 +12,7 @@ labels:
|
||||
|
||||
The `nft_history` command asks the Clio server for past transaction metadata for the [NFT](../../../../concepts/tokens/nfts/index.md) being queried. {% badge href="https://github.com/XRPLF/clio/releases/tag/1.1.0" %}New in: Clio v1.1.0{% /badge %}
|
||||
|
||||
**Note** `nft_history` returns only _successful_ transactions associated with the NFT.
|
||||
{% admonition type="info" name="Note" %}`nft_history` returns only _successful_ transactions associated with the NFT.{% /admonition %}
|
||||
|
||||
## Request Format
|
||||
An example of the request format:
|
||||
@@ -60,7 +60,7 @@ The request contains the following parameters:
|
||||
| `limit` | UInt32 | _(Optional)_ Limit the number of NFTs to retrieve. The server is not required to honor this value. |
|
||||
| `marker` | Marker | Value from a previous paginated response. Resume retrieving data where that response left off. This value is NOT stable if there is a change in the server's range of available ledgers. If you are querying the “validated” ledger, it is possible that new NFTs are created during your paging. |
|
||||
|
||||
**Note** If you do not specify a ledger version, Clio uses the latest validated ledger.
|
||||
{% admonition type="info" name="Note" %}If you do not specify a ledger version, Clio uses the latest validated ledger.{% /admonition %}
|
||||
|
||||
## Response Format
|
||||
|
||||
@@ -315,7 +315,7 @@ The response follows the [standard format][], with a successful result containin
|
||||
| `transactions` | Array | Array of transactions matching the request's criteria, as explained below. |
|
||||
| `validated` | Boolean | If included and set to `true`, the information in this response comes from a validated ledger version. Otherwise, the information is subject to change. |
|
||||
|
||||
**Note:** The server may respond with different values of `ledger_index_min` and `ledger_index_max` than you provided in the request, for example if it did not have the versions you specified on hand.
|
||||
{% admonition type="info" name="Note" %}The server may respond with different values of `ledger_index_min` and `ledger_index_max` than you provided in the request, for example if it did not have the versions you specified on hand.{% /admonition %}
|
||||
|
||||
Each transaction object includes the following fields, depending on whether it was requested in JSON or hex string (`"binary":true`) format.
|
||||
|
||||
|
||||
@@ -36,7 +36,7 @@ The request contains the following parameters:
|
||||
| `limit` | Integer | _(Optional)_ Limit the number of NFTs to retrieve. The server is not required to honor this value.|
|
||||
|
||||
|
||||
**Note** If you do not specify a ledger version, Clio uses the latest validated ledger.
|
||||
{% admonition type="info" name="Note" %}If you do not specify a ledger version, Clio uses the latest validated ledger.{% /admonition %}
|
||||
|
||||
## Response Format
|
||||
|
||||
|
||||
@@ -51,7 +51,7 @@ In addition to the general fields above, you must specify *exactly 1* of the fol
|
||||
- [Response Format](#response-format)
|
||||
- [Possible Errors](#possible-errors)
|
||||
|
||||
**Caution:** If you specify more than 1 of these type-specific fields in a request, the server retrieves results for only 1 of them. It is not defined which one the server chooses, so you should avoid doing this.
|
||||
{% admonition type="warning" name="Caution" %}If you specify more than 1 of these type-specific fields in a request, the server retrieves results for only 1 of them. It is not defined which one the server chooses, so you should avoid doing this.{% /admonition %}
|
||||
|
||||
|
||||
### Get Ledger Object by ID
|
||||
|
||||
@@ -136,7 +136,7 @@ The response follows the [standard format][], with a successful result containin
|
||||
| `source_account` | String - [Address][] | The source account specified in the request. |
|
||||
| `validated` | Boolean | _(May be omitted)_ If `true`, the information comes from a validated ledger version. |
|
||||
|
||||
**Note:** A `deposit_authorized` status of `true` does not guarantee that a payment can be sent from the specified source to the specified destination. For example, the destination account may not have a [trust line](../../../../concepts/tokens/fungible-tokens/index.md) for the specified currency, or there may not be enough liquidity to deliver a payment.
|
||||
{% admonition type="info" name="Note" %}A `deposit_authorized` status of `true` does not guarantee that a payment can be sent from the specified source to the specified destination. For example, the destination account may not have a [trust line](../../../../concepts/tokens/fungible-tokens/index.md) for the specified currency, or there may not be enough liquidity to deliver a payment.{% /admonition %}
|
||||
|
||||
## Possible Errors
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ The `ripple_path_find` method is a simplified version of the [path_find method][
|
||||
|
||||
Although the `rippled` server tries to find the cheapest path or combination of paths for making a payment, it is not guaranteed that the paths returned by this method are, in fact, the best paths.
|
||||
|
||||
**Caution:** Be careful with the pathfinding results from untrusted servers. A server could be modified to return less-than-optimal paths to earn money for its operators. A server may also return poor results when under heavy load. If you do not have your own server that you can trust with pathfinding, you should compare the results of pathfinding from multiple servers run by different parties, to minimize the risk of a single server returning poor results.
|
||||
{% admonition type="warning" name="Caution" %}Be careful with the pathfinding results from untrusted servers. A server could be modified to return less-than-optimal paths to earn money for its operators. A server may also return poor results when under heavy load. If you do not have your own server that you can trust with pathfinding, you should compare the results of pathfinding from multiple servers run by different parties, to minimize the risk of a single server returning poor results.{% /admonition %}
|
||||
|
||||
## Request Format
|
||||
An example of the request format:
|
||||
|
||||
@@ -71,7 +71,7 @@ The request includes the following parameters:
|
||||
|
||||
The request **must** specify exactly one of `secret`, `seed`, `seed_hex`, or `passphrase`.
|
||||
|
||||
**Warning:** Do not send secret keys to untrusted servers or through unsecured network connections. (This includes the `secret`, `seed`, `seed_hex`, or `passphrase` fields of this request.) You should only use this method on a secure, encrypted network connection to a server you run or fully trust with your funds. Otherwise, eavesdroppers could use your secret key to sign claims and take all the money from this payment channel and anything else using the same key pair. See [Set Up Secure Signing](../../../../concepts/transactions/secure-signing.md) for instructions.
|
||||
{% admonition type="danger" name="Warning" %}Do not send secret keys to untrusted servers or through unsecured network connections. (This includes the `secret`, `seed`, `seed_hex`, or `passphrase` fields of this request.) You should only use this method on a secure, encrypted network connection to a server you run or fully trust with your funds. Otherwise, eavesdroppers could use your secret key to sign claims and take all the money from this payment channel and anything else using the same key pair. See [Set Up Secure Signing](../../../../concepts/transactions/secure-signing.md) for instructions.{% /admonition %}
|
||||
|
||||
## Response Format
|
||||
|
||||
|
||||
@@ -114,7 +114,7 @@ The response follows the [standard format][], with a successful result containin
|
||||
|-------|------|-------------|
|
||||
| `signature_verified` | Boolean | If `true`, the signature is valid for the stated amount, channel, and public key. |
|
||||
|
||||
**Caution:** This does not indicate check that the channel has enough XRP allocated to it. Before considering a claim valid, you should look up the channel in the latest validated ledger and confirm that the channel is open and its `amount` value is equal or greater than the `amount` of the claim. To do so, use the [account_channels method][].
|
||||
{% admonition type="warning" name="Caution" %}This does not indicate check that the channel has enough XRP allocated to it. Before considering a claim valid, you should look up the channel in the latest validated ledger and confirm that the channel is open and its `amount` value is equal or greater than the `amount` of the claim. To do so, use the [account_channels method][].{% /admonition %}
|
||||
|
||||
## Possible Errors
|
||||
|
||||
|
||||
@@ -128,7 +128,7 @@ The `info` object may have some arrangement of the following fields:
|
||||
| `counters` | Object | This object contains performance metrics pertaining to the RPC calls (currently executing calls and completed calls) and the JobQueue. It also contains details of the nodestore like `node_writes`, `node_reads_total`, `node_reads_hit`, etc|
|
||||
| `current_activity` | Object | This field lists the items currently being run in the job queue and contains two arrays for `jobs` and `methods`. |
|
||||
|
||||
**Note:** If the `closed_ledger` field is present and has a small `seq` value (less than 8 digits), that indicates `rippled` does not currently have a copy of the validated ledger from the peer-to-peer network. This could mean your server is still syncing. Typically, it takes about 5 minutes to sync with the network, depending on your connection speed and hardware specs.
|
||||
{% admonition type="info" name="Note" %}If the `closed_ledger` field is present and has a small `seq` value (less than 8 digits), that indicates `rippled` does not currently have a copy of the validated ledger from the peer-to-peer network. This could mean your server is still syncing. Typically, it takes about 5 minutes to sync with the network, depending on your connection speed and hardware specs.{% /admonition %}
|
||||
|
||||
{% partial file="/docs/_snippets/etl-source-object.md" /%}
|
||||
|
||||
|
||||
@@ -87,11 +87,11 @@ The `streams` parameter provides access to the following default streams of info
|
||||
- `peer_status` - **(Admin only)** Information about connected peer `rippled` servers, especially with regards to the consensus process.
|
||||
- `transactions` - Sends a message whenever a transaction is included in a closed ledger.
|
||||
- `transactions_proposed` - Sends a message whenever a transaction is included in a closed ledger, as well as some transactions that have not yet been included in a validated ledger and may never be. Not all proposed transactions appear before validation.
|
||||
**Note:** [Even some transactions that don't succeed are included](../../../protocol/transactions/transaction-results/index.md) in validated ledgers, because they take the anti-spam transaction fee.
|
||||
{% admonition type="info" name="Note" %}[Even some transactions that don't succeed are included](../../../protocol/transactions/transaction-results/index.md) in validated ledgers, because they take the anti-spam transaction fee.{% /admonition %}
|
||||
- `server` - Sends a message whenever the status of the `rippled` server (for example, network connectivity) changes.
|
||||
- `validations` - Sends a message whenever the server receives a validation message, regardless of if the server trusts the validator. (An individual `rippled` declares a ledger validated when the server receives validation messages from at least a quorum of trusted validators.)
|
||||
|
||||
**Note:** The following streams are not available from Clio and `rippled` servers in [Reporting Mode][]: `server`, `peer_status`, `consensus`. Both will return the `reportingUnsupported` error if you request one of these streams. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.8.1" %}Updated in: rippled 1.8.1{% /badge %} {% badge href="https://github.com/XRPLF/clio/releases/tag/2.0.0" %}New in: Clio v2.0{% /badge %}
|
||||
{% admonition type="info" name="Note" %}The following streams are not available from Clio and `rippled` servers in [Reporting Mode][]: `server`, `peer_status`, `consensus`. Both will return the `reportingUnsupported` error if you request one of these streams. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.8.1" %}Updated in: rippled 1.8.1{% /badge %} {% badge href="https://github.com/XRPLF/clio/releases/tag/2.0.0" %}New in: Clio v2.0{% /badge %}{% /admonition %}
|
||||
|
||||
Each member of the `books` array, if provided, is an object with the following fields:
|
||||
|
||||
|
||||
@@ -308,9 +308,9 @@ The response follows the [standard format][], with a successful result containin
|
||||
| `open_ledger_cost` | String | _(Omitted in sign-and-submit mode)_ The current [open ledger cost](../../../../concepts/transactions/transaction-cost.md#open-ledger-cost) before processing this transaction. Transactions with a lower cost are likely to be [queued](../../../../concepts/transactions/transaction-queue.md). |
|
||||
| `validated_ledger_index` | Integer | _(Omitted in sign-and-submit mode)_ The [ledger index][] of the newest validated ledger at the time of submission. This provides a lower bound on the ledger versions that the transaction can appear in as a result of this request. (The transaction could only have been validated in this ledger version or earlier if it had already been submitted before.) |
|
||||
|
||||
**Warning:** Even if the WebSocket response has `"status":"success"`, indicating that the command was successfully received, that does _not_ indicate that the transaction executed successfully. Many situations can prevent a transaction from processing successfully, such as a lack of trust lines connecting the two accounts in a payment, or changes in the state of the ledger since the time the transaction was constructed. Even if nothing is wrong, it may take several seconds to close and validate the ledger version that includes the transaction. See the [full list of transaction responses](../../../protocol/transactions/transaction-results/index.md) for details, and do not consider the transaction's results final until they appear in a validated ledger version.
|
||||
{% admonition type="danger" name="Warning" %}Even if the WebSocket response has `"status":"success"`, indicating that the command was successfully received, that does _not_ indicate that the transaction executed successfully. Many situations can prevent a transaction from processing successfully, such as a lack of trust lines connecting the two accounts in a payment, or changes in the state of the ledger since the time the transaction was constructed. Even if nothing is wrong, it may take several seconds to close and validate the ledger version that includes the transaction. See the [full list of transaction responses](../../../protocol/transactions/transaction-results/index.md) for details, and do not consider the transaction's results final until they appear in a validated ledger version.{% /admonition %}
|
||||
|
||||
**Caution:** If this command results in an error message, the message can contain the secret key from the request. (This can only happen in sign-and-submit mode.) Make sure that these errors are not visible to others.
|
||||
{% admonition type="warning" name="Caution" %}If this command results in an error message, the message can contain the secret key from the request. (This can only happen in sign-and-submit mode.) Make sure that these errors are not visible to others.{% /admonition %}
|
||||
|
||||
* Do not write an error including your secret key to a log file that can be seen by multiple people.
|
||||
* Do not paste an error including your secret key to a public place for debugging.
|
||||
|
||||
@@ -61,7 +61,7 @@ The request includes the following parameters:
|
||||
| `ledger_index` | String or Unsigned Integer | _(Optional)_ The [ledger index][] of the ledger to use, or a shortcut string to choose a ledger automatically. (See [Specifying Ledgers][]) |
|
||||
| `tx_hash` | String | Unique hash of the transaction you are looking up |
|
||||
|
||||
**Note:** This method does not support retrieving information from the current in-progress ledger. You must specify a ledger version in either `ledger_index` or `ledger_hash`.
|
||||
{% admonition type="info" name="Note" %}This method does not support retrieving information from the current in-progress ledger. You must specify a ledger version in either `ledger_index` or `ledger_hash`.{% /admonition %}
|
||||
|
||||
## Response Format
|
||||
|
||||
|
||||
@@ -92,7 +92,7 @@ The request includes the following parameters:
|
||||
|
||||
You must provide _either_ `ctid` or `transaction`, but not both.
|
||||
|
||||
**Caution:** This command may successfully find the transaction even if it is included in a ledger _outside_ the range of `min_ledger` to `max_ledger`.
|
||||
{% admonition type="warning" name="Caution" %}This command may successfully find the transaction even if it is included in a ledger _outside_ the range of `min_ledger` to `max_ledger`.{% /admonition %}
|
||||
|
||||
## Response Format
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ seo:
|
||||
|
||||
The `tx_history` method retrieves some of the most recent transactions made.
|
||||
|
||||
**Caution:** This method is removed in [API v2][].
|
||||
{% admonition type="warning" name="Caution" %}This method is removed in [API v2][].{% /admonition %}
|
||||
|
||||
## Request Format
|
||||
An example of the request format:
|
||||
|
||||
Reference in New Issue
Block a user