mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-20 03:35:51 +00:00
Link fixes around subscriptions & others
This commit is contained in:
@@ -9,7 +9,7 @@ The fields of a successful response include:
|
||||
| `id` | (Varies) | (WebSocket only) ID provided in the request that prompted this response |
|
||||
| `status` | String | (WebSocket only) The value `success` indicates the request was successfully received and understood by the server. |
|
||||
| `result.status` | String | (JSON-RPC and Commandline) The value `success` indicates the request was successfully received and understood by the server. |
|
||||
| `type` | String | (WebSocket only) The value `response` indicates a successful response to a command. [Asynchronous notifications](#subscriptions) use a different value such as `ledgerClosed` or `transaction`. |
|
||||
| `type` | String | (WebSocket only) The value `response` indicates a successful response to a command. [Asynchronous notifications](subscribe.html) use a different value such as `ledgerClosed` or `transaction`. |
|
||||
| `result` | Object | The result of the query; contents vary depending on the command. |
|
||||
|
||||
|
||||
|
||||
@@ -3,7 +3,9 @@
|
||||
|
||||
The `Offer` object type describes an offer to exchange currencies, more traditionally known as an _order_, in the XRP Ledger's distributed exchange. An [OfferCreate transaction][] only creates an `Offer` object in the ledger when the offer cannot be fully executed immediately by consuming other offers already in the ledger.
|
||||
|
||||
An offer can become unfunded through other activities in the network, while remaining in the ledger. However, `rippled` automatically prunes any unfunded offers it happens across in the course of transaction processing (and _only_ transaction processing, because the ledger state must only be changed by transactions). For more information, see [lifecycle of an offer](reference-transaction-format.html#lifecycle-of-an-offer).
|
||||
An offer can become unfunded through other activities in the network, while remaining in the ledger. However, `rippled` automatically prunes any unfunded offers it happens across in the course of transaction processing (and _only_ transaction processing, because the ledger state must only be changed by transactions).
|
||||
|
||||
For more information, see [Offers](offers.html).
|
||||
|
||||
## Example {{currentpage.name}} JSON
|
||||
|
||||
|
||||
@@ -184,7 +184,7 @@ The `queue_data` parameter, if present, contains the following fields:
|
||||
| `Field` | Type | Description |
|
||||
|:------------------------|:--------|:-----------------------------------------|
|
||||
| `txn_count` | Integer | Number of queued transactions from this address. |
|
||||
| `auth_change_queued` | Boolean | (May be omitted) Whether a transaction in the queue changes this address's [ways of authorizing transactions](reference-transaction-format.html#authorizing-transactions). If `true`, this address can queue no further transactions until that transaction has been executed or dropped from the queue. |
|
||||
| `auth_change_queued` | Boolean | (May be omitted) Whether a transaction in the queue changes this address's [ways of authorizing transactions](transaction-basics.html#authorizing-transactions). If `true`, this address can queue no further transactions until that transaction has been executed or dropped from the queue. |
|
||||
| `lowest_sequence` | Integer | (May be omitted) The lowest [Sequence Number][] among transactions queued by this address. |
|
||||
| `highest_sequence` | Integer | (May be omitted) The highest [Sequence Number][] among transactions queued by this address. |
|
||||
| `max_spend_drops_total` | String | (May be omitted) Integer amount of [drops of XRP][] that could be debited from this address if every transaction in the queue consumes the maximum amount of XRP possible. |
|
||||
@@ -194,7 +194,7 @@ Each object in the `transactions` array, if present, may contain any or all of t
|
||||
|
||||
| `Field` | Type | Description |
|
||||
|:------------------|:--------|:-----------------------------------------------|
|
||||
| `auth_change` | Boolean | Whether this transaction changes this address's [ways of authorizing transactions](reference-transaction-format.html#authorizing-transactions). |
|
||||
| `auth_change` | Boolean | Whether this transaction changes this address's [ways of authorizing transactions](transaction-basics.html#authorizing-transactions). |
|
||||
| `fee` | String | The [Transaction Cost](transaction-cost.html) of this transaction, in [drops of XRP][]. |
|
||||
| `fee_level` | String | The transaction cost of this transaction, relative to the minimum cost for this type of transaction, in [fee levels][]. |
|
||||
| `max_spend_drops` | String | The maximum amount of [XRP, in drops][], this transaction could send or destroy. |
|
||||
@@ -207,6 +207,6 @@ Each object in the `transactions` array, if present, may contain any or all of t
|
||||
* `actNotFound` - The address specified in the `account` field of the request does not correspond to an account in the ledger.
|
||||
* `lgrNotFound` - The ledger specified by the `ledger_hash` or `ledger_index` does not exist, or it does exist but the server does not have it.
|
||||
|
||||
|
||||
[fee levels]: transaction-cost.html#fee-levels
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# account_objects
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/399c43cae6e90a428e9ce6a988123972b0f03c99/src/ripple/rpc/handlers/AccountObjects.cpp "Source")
|
||||
|
||||
The `account_objects` command returns the raw [ledger format][] for all objects owned by an account. For a higher-level view of an account's trust lines and balances, see [`account_lines`](#account-lines) instead.
|
||||
The `account_objects` command returns the raw [ledger format][] for all objects owned by an account. For a higher-level view of an account's trust lines and balances, see the [account_lines method][] instead.
|
||||
|
||||
[ledger format]: ledger-data-formats.html
|
||||
|
||||
The types of objects that may appear in the `account_objects` response for an account include:
|
||||
|
||||
- [Offer objects](offer.html) for orders that are currently live, unfunded, or expired but not yet removed. (See [Lifecycle of an Offer](reference-transaction-format.html#lifecycle-of-an-offer) for more information.)
|
||||
- [Offer objects](offer.html) for orders that are currently live, unfunded, or expired but not yet removed. (See [Lifecycle of an Offer](offers.html#lifecycle-of-an-offer) for more information.)
|
||||
- [RippleState objects](ripplestate.html) for trust lines where this account's side is not in the default state.
|
||||
- The account's [SignerList](signerlist.html), if the account has [multi-signing](multi-signing.html) enabled.
|
||||
- [Escrow objects](escrow.html) for held payments that have not yet been executed or canceled.
|
||||
|
||||
@@ -45,7 +45,7 @@ An example of the request format:
|
||||
This method can retrieve several different types of data. You can select which type of item to retrieve by passing the appropriate parameters. Specifically, you should provide exactly one of the following fields:
|
||||
|
||||
1. `index` - Retrieve any type of ledger object by its unique ID
|
||||
2. `account_root` - Retrieve an [AccountRoot object](accountroot.html). This is roughly equivalent to the [account_info](#account-info) command.
|
||||
2. `account_root` - Retrieve an [AccountRoot object](accountroot.html). This is roughly equivalent to the [account_info method][].
|
||||
3. `directory` - Retrieve a [DirectoryNode](directorynode.html), which contains a list of other ledger objects
|
||||
4. `offer` - Retrieve an [Offer object](offer.html), which defines an offer to exchange currency
|
||||
5. `ripple_state` - Retrieve a [RippleState object](ripplestate.html), which tracks a (non-XRP) currency balance between two accounts.
|
||||
@@ -148,6 +148,6 @@ The response follows the [standard format][], with a successful result containin
|
||||
|
||||
|
||||
<!-- TODO: we should add this ledger format link to rippled-api-links.md. account_objects.md is also including this as a one-off.-->
|
||||
[ledger format]: reference-ledger-format.html
|
||||
[ledger format]: ledger-data-formats.html
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# ripple_path_find
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/RipplePathFind.cpp "Source")
|
||||
|
||||
The `ripple_path_find` method is a simplified version of [`path_find`](#path-find) that provides a single response with a [payment path](paths.html) you can use right away. It is available in both the WebSocket and JSON-RPC APIs. However, the results tend to become outdated as time passes. Instead of making multiple calls to stay updated, you should use [`path_find`](#path-find) instead where possible.
|
||||
The `ripple_path_find` method is a simplified version of the [path_find method][] that provides a single response with a [payment path](paths.html) you can use right away. It is available in both the WebSocket and JSON-RPC APIs. However, the results tend to become outdated as time passes. Instead of making multiple calls to stay updated, you should instead use the [path_find method][] to subscribe to continued updates where possible.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
@@ -73,7 +73,7 @@ The `streams` parameter provides access to the following default streams of info
|
||||
* `ledger` - Sends a message whenever the consensus process declares a new validated ledger
|
||||
* `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](reference-transaction-format.html#result-categories) in validated ledgers, because they take the anti-spam transaction fee.
|
||||
**Note:** [Even some transactions that don't succeed are included](transaction-results.html) in validated ledgers, because they take the anti-spam transaction fee.
|
||||
* `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.)
|
||||
* `peer_status` - **(Admin only)** Information about connected peer `rippled` servers, especially with regards to the consensus process.
|
||||
|
||||
@@ -81,8 +81,8 @@ Each member of the `books` array, if provided, is an object with the following f
|
||||
|
||||
| `Field` | Type | Description |
|
||||
|:-------------|:--------|:----------------------------------------------------|
|
||||
| `taker_gets` | Object | Specification of which currency the account taking the offer would receive, as a [currency object with no amount](#specifying-currencies-without-amounts). |
|
||||
| `taker_pays` | Object | Specification of which currency the account taking the offer would pay, as a [currency object with no amount](#specifying-currencies-without-amounts). |
|
||||
| `taker_gets` | Object | Specification of which currency the account taking the offer would receive, as a [currency object with no amount](basic-data-types.html#specifying-currencies-without-amounts). |
|
||||
| `taker_pays` | Object | Specification of which currency the account taking the offer would pay, as a [currency object with no amount](basic-data-types.html#specifying-currencies-without-amounts). |
|
||||
| `taker` | String | Unique [base58][] account address to use as a perspective for viewing offers. (This affects the funding status and fees of offers.) |
|
||||
| `snapshot` | Boolean | (Optional, defaults to false) If true, return the current state of the order book once when you subscribe before sending updates |
|
||||
| `both` | Boolean | (Optional, defaults to false) If true, return both sides of the order book. |
|
||||
@@ -154,13 +154,13 @@ The fields from a ledger stream message are as follows:
|
||||
| `Field` | Type | Description |
|
||||
|:--------------------|:-----------------|:------------------------------------|
|
||||
| `type` | String | `ledgerClosed` indicates this is from the ledger stream |
|
||||
| `fee_base` | Unsigned Integer | Cost of the 'reference transaction' in drops of XRP. (See [Transaction Cost](transaction-cost.html) If the ledger includes a [SetFee pseudo-transaction](reference-transaction-format.html#setfee) the new transaction cost applies to all transactions after this ledger. |
|
||||
| `fee_base` | Unsigned Integer | Cost of the 'reference transaction' in drops of XRP. (See [Transaction Cost](transaction-cost.html) If the ledger includes a [SetFee pseudo-transaction](setfee.html) the new transaction cost applies to all transactions after this ledger. |
|
||||
| `fee_ref` | Unsigned Integer | Cost of the 'reference transaction' in 'fee units'. |
|
||||
| `ledger_hash` | String | Unique hash of the ledger that was closed, as hex |
|
||||
| `ledger_index` | Unsigned Integer | Sequence number of the ledger that was closed |
|
||||
| `ledger_time` | Unsigned Integer | The time this ledger was closed, in [seconds since the Ripple Epoch][] |
|
||||
| `reserve_base` | Unsigned Integer | The minimum reserve, in drops of XRP, that is required for an account. If the ledger includes a [SetFee pseudo-transaction](reference-transaction-format.html#setfee) the new base reserve applies after this ledger. |
|
||||
| `reserve_inc` | Unsigned Integer | The increase in account reserve that is added for each item the account owns, such as offers or trust lines. If the ledger includes a [SetFee pseudo-transaction](reference-transaction-format.html#setfee) the new owner reserve applies after this ledger. |
|
||||
| `reserve_base` | Unsigned Integer | The minimum reserve, in drops of XRP, that is required for an account. If the ledger includes a [SetFee pseudo-transaction](setfee.html) the new base reserve applies after this ledger. |
|
||||
| `reserve_inc` | Unsigned Integer | The increase in account reserve that is added for each item the account owns, such as offers or trust lines. If the ledger includes a [SetFee pseudo-transaction](setfee.html) the new owner reserve applies after this ledger. |
|
||||
| `txn_count` | Unsigned Integer | Number of new transactions included in this ledger |
|
||||
| `validated_ledgers` | String | (May be omitted) Range of ledgers that the server has available. This may be discontiguous. This field is not returned if the server is not connected to the network, or if it is connected but has not yet obtained a ledger from the network. |
|
||||
|
||||
@@ -341,8 +341,8 @@ Transaction stream messages have the following fields:
|
||||
| `Field` | Type | Description |
|
||||
|:------------------------|:-----------------|:--------------------------------|
|
||||
| `type` | String | `transaction` indicates this is the notification of a transaction, which could come from several possible streams. |
|
||||
| `engine_result` | String | String [Transaction result code](reference-transaction-format.html#result-categories) |
|
||||
| `engine_result_code` | Number | Numeric [transaction response code](reference-transaction-format.html#result-categories), if applicable. |
|
||||
| `engine_result` | String | String [Transaction result code](transaction-results.html) |
|
||||
| `engine_result_code` | Number | Numeric [transaction response code](transaction-results.html), if applicable. |
|
||||
| `engine_result_message` | String | Human-readable explanation for the transaction response |
|
||||
| `ledger_current_index` | Unsigned Integer | (Omitted for validated transactions) Sequence number of the current ledger version for which this transaction is currently proposed |
|
||||
| `ledger_hash` | String | (Omitted for unvalidated transactions) Unique hash of the ledger version that includes this transaction, as hex |
|
||||
|
||||
@@ -36,7 +36,7 @@ An example of the request format:
|
||||
|
||||
[Try it! >](websocket-api-tool.html#unsubscribe)
|
||||
|
||||
The parameters in the request are specified almost exactly like the parameters to [`subscribe`](#subscribe), except that they are used to define which subscriptions to end instead. The parameters are:
|
||||
The parameters in the request are specified almost exactly like the parameters to the [subscribe method][], except that they are used to define which subscriptions to end instead. The parameters are:
|
||||
|
||||
| `Field` | Type | Description |
|
||||
|:--------------------|:------|:-----------------------------------------------|
|
||||
|
||||
@@ -68,7 +68,7 @@ rippled sign s██████████████████████
|
||||
|
||||
[Try it! >](websocket-api-tool.html#sign)
|
||||
|
||||
To sign a transaction, you must provide a secret key that can [authorize the transaction](reference-transaction-format.html#authorizing-transactions). You can do this in a few ways:
|
||||
To sign a transaction, you must provide a secret key that can [authorize the transaction](transaction-basics.html#authorizing-transactions). You can do this in a few ways:
|
||||
|
||||
* Provide a `secret` value and omit the `key_type` field. This value can be formatted as [base58][] seed, RFC-1751, hexadecimal, or as a string passphrase. (secp256k1 keys only)
|
||||
* Provide a `key_type` value and exactly one of `seed`, `seed_hex`, or `passphrase`. Omit the `secret` field. (Not supported by the commandline syntax.)
|
||||
|
||||
@@ -10,7 +10,7 @@ Reliably submitting transactions is the process of achieving both of the followi
|
||||
|
||||
To have both qualities when submitting a transaction, an application should:
|
||||
|
||||
1. Construct and sign the transaction first, including a [`LastLedgerSequence`](#lastledgersequence) parameter that gives the transaction a limited lifespan.
|
||||
1. Construct and sign the transaction first, including a [`LastLedgerSequence`](reliable-transaction-submission.html#lastledgersequence) parameter that gives the transaction a limited lifespan.
|
||||
2. Persist details of the transaction before submitting.
|
||||
3. Submit the transaction.
|
||||
4. Confirm that the transaction was either included in a validated ledger, or that it has expired due to `LastLedgerSequence`.
|
||||
|
||||
@@ -21,7 +21,7 @@ For the most part, transactions with `tec` codes take no action other than to de
|
||||
| `tecINTERNAL` | 144 | Unspecified internal error, with transaction cost applied. This error code should not normally be returned. If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues). |
|
||||
| `tecINVARIANT_FAILED` | 147 | An invariant check failed when trying to execute this transaction. Requires the [EnforceInvariants amendment](known-amendments.html#enforceinvariants). If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues). |
|
||||
| `tecNEED_MASTER_KEY` | 142 | This transaction tried to cause changes that require the master key, such as [disabling the master key or giving up the ability to freeze balances](accountset.html#accountset-flags). [New in: rippled 0.28.0][] |
|
||||
| `tecNO_ALTERNATIVE_KEY` | 130 | The transaction tried to remove the only available method of [authorizing transactions](#authorizing-transactions). This could be a [SetRegularKey transaction][] to remove the regular key, a [SignerListSet transaction][] to delete a SignerList, or an [AccountSet transaction][] to disable the master key. (Prior to `rippled` 0.30.0, this was called `tecMASTER_DISABLED`.) |
|
||||
| `tecNO_ALTERNATIVE_KEY` | 130 | The transaction tried to remove the only available method of [authorizing transactions](transaction-basics.html#authorizing-transactions). This could be a [SetRegularKey transaction][] to remove the regular key, a [SignerListSet transaction][] to delete a SignerList, or an [AccountSet transaction][] to disable the master key. (Prior to `rippled` 0.30.0, this was called `tecMASTER_DISABLED`.) |
|
||||
| `tecNO_AUTH` | 134 | The transaction failed because it needs to add a balance on a trust line to an account with the `lsfRequireAuth` flag enabled, and that trust line has not been authorized. If the trust line does not exist at all, `tecNO_LINE` occurs instead. |
|
||||
| `tecNO_DST` | 124 | The account on the receiving end of the transaction does not exist. This includes Payment and TrustSet transaction types. (It could be created if it received enough XRP.) |
|
||||
| `tecNO_DST_INSUF_XRP` | 125 | The account on the receiving end of the transaction does not exist, and the transaction is not sending enough XRP to create it. |
|
||||
@@ -31,7 +31,7 @@ For the most part, transactions with `tec` codes take no action other than to de
|
||||
| `tecNO_LINE_INSUF_RESERVE` | 126 | The transaction failed because the sending account does not have enough XRP to create a new trust line. (See: [Reserves](reserves.html)) This error occurs when the counterparty does not have a trust line to this account for the same currency. (See `tecINSUF_RESERVE_LINE` for the other case.) |
|
||||
| `tecNO_LINE_REDUNDANT` | 127 | The transaction failed because it tried to set a trust line to its default state, but the trust line did not exist. |
|
||||
| `tecNO_PERMISSION` | 139 | The sender does not have permission to do this operation. For example, the [EscrowFinish transaction][] tried to release a held payment before its `FinishAfter` time, someone tried to use [PaymentChannelFund][] on a channel the sender does not own, or a [Payment][] tried to deliver funds to an account with the "DepositAuth" flag enabled. |
|
||||
| `tecNO_REGULAR_KEY` | 131 | The [AccountSet transaction][] tried to disable the master key, but the account does not have another way to [authorize transactions](#authorizing-transactions). If [multi-signing](multi-signing.html) is enabled, this code is deprecated and `tecNO_ALTERNATIVE_KEY` is used instead. |
|
||||
| `tecNO_REGULAR_KEY` | 131 | The [AccountSet transaction][] tried to disable the master key, but the account does not have another way to [authorize transactions](transaction-basics.html#authorizing-transactions). If [multi-signing](multi-signing.html) is enabled, this code is deprecated and `tecNO_ALTERNATIVE_KEY` is used instead. |
|
||||
| `tecNO_TARGET` | 138 | The transaction referenced an Escrow or PayChannel ledger object that doesn't exist, either because it never existed or it has already been deleted. (For example, another [EscrowFinish transaction][] has already executed the held payment.) Alternatively, the destination account has `asfDisallowXRP` set so it cannot be the destination of this [PaymentChannelCreate][] or [EscrowCreate][] transaction. |
|
||||
| `tecOVERSIZE` | 145 | This transaction could not be processed, because the server created an excessively large amount of metadata when it tried to apply the transaction. [New in: rippled 0.29.0-hf1][] |
|
||||
| `tecOWNERS` | 132 | The transaction requires that account sending it has a nonzero "owners count", so the transaction cannot succeed. For example, an account cannot enable the [`lsfRequireAuth`](accountset.html#accountset-flags) flag if it has any trust lines or available offers. |
|
||||
|
||||
@@ -19,7 +19,7 @@ These codes indicate that the transaction failed and was not included in a ledge
|
||||
| `tefINTERNAL` | When trying to apply the transaction, the server entered an unexpected state. If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues) to get it fixed. |
|
||||
| `tefINVARIANT_FAILED` | An invariant check failed when trying to claim the [transaction cost](transaction-cost.html). Requires the [EnforceInvariants amendment](known-amendments.html#enforceinvariants). If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues). |
|
||||
| `tefMASTER_DISABLED` | The transaction was signed with the account's master key, but the account has the `lsfDisableMaster` field set. |
|
||||
| `tefMAX_LEDGER` | The transaction included a [`LastLedgerSequence`](#lastledgersequence) parameter, but the current ledger's sequence number is already higher than the specified value. |
|
||||
| `tefMAX_LEDGER` | The transaction included a [`LastLedgerSequence`](reliable-transaction-submission.html#lastledgersequence) parameter, but the current ledger's sequence number is already higher than the specified value. |
|
||||
| `tefNO_AUTH_REQUIRED` | The [TrustSet transaction][] tried to mark a trustline as authorized, but the `lsfRequireAuth` flag is not enabled for the corresponding account, so authorization is not necessary. |
|
||||
| `tefNOT_MULTI_SIGNING` | The transaction was [multi-signed](multi-signing.html), but the sending account has no SignerList defined. |
|
||||
| `tefPAST_SEQ` | The sequence number of the transaction is lower than the current sequence number of the account sending the transaction. |
|
||||
|
||||
Reference in New Issue
Block a user