ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-20 11:45:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

headings, includes, blurbs

Browse Source
This commit is contained in:
Jennifer Hasegawa
2018-05-10 14:28:16 -07:00
parent 678a9af5d2
commit cb8067ce8e
36 changed files with 345 additions and 278 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
content/references/rippled-api/public-rippled-methods/account-methods/account_channels.md
View File

@@ -1,11 +1,11 @@
## account_channels
# account_channels
[[Source]<br>](https://github.com/ripple/rippled/blob/release/src/ripple/rpc/handlers/AccountChannels.cpp "Source")
_(Requires the [PayChan amendment](reference-amendments.html#paychan) to be enabled. [New in: rippled 0.33.0][])_
The `account_channels` method returns information about an account's Payment Channels. This includes only channels where the specified account is the channel's source, not the destination. (A channel's "source" and "owner" are the same.) All information retrieved is relative to a particular version of the ledger.
#### Request Format
## Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
@@ -55,7 +55,7 @@ The request includes the following parameters:
| `limit` | Integer | _(Optional)_ Limit the number of transactions to retrieve. The server is not required to honor this value. Must be within the inclusive range 10 to 400. Defaults to 200. |
| `marker` | [(Not Specified)](#markers-and-pagination) | _(Optional)_ Value from a previous paginated response. Resume retrieving data where that response left off. |
#### Response Format
## Response Format
An example of a successful response:
@@ -176,9 +176,13 @@ Each Channel Object has the following fields:
| `source_tag` | Unsigned Integer | _(May be omitted)_ A 32-bit unsigned integer to use as a [source tag](tutorial-gateway-guide.html#source-and-destination-tags) for payments through this payment channel, if one was specified at channel creation. This indicates the payment channel's originator or other purpose at the source account. Conventionally, if you bounce payments from this channel, you should specify this value in the `DestinationTag` of the return payment. |
| `destination_tag` | Unsigned Integer | _(May be omitted)_ A 32-bit unsigned integer to use as a [destination tag](tutorial-gateway-guide.html#source-and-destination-tags) for payments through this channel, if one was specified at channel creation. This indicates the payment channel's beneficiary or other purpose at the destination account. |
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
* `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.
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

11
content/references/rippled-api/public-rippled-methods/account-methods/account_currencies.md
View File

@@ -1,9 +1,9 @@
## account_currencies
# account_currencies
[[Source]<br>](https://github.com/ripple/rippled/blob/df966a9ac6dd986585ecccb206aff24452e41a30/src/ripple/rpc/handlers/AccountCurrencies.cpp "Source")
The `account_currencies` command retrieves a list of currencies that an account can send or receive, based on its trust lines. (This is not a thoroughly confirmed list, but it can be used to populate user interfaces.)
#### Request Format
## Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
@@ -50,7 +50,7 @@ The request includes the following parameters:
The following field is deprecated and should not be provided: `account_index`.
#### Response Format
## Response Format
An example of a successful response:
@@ -140,9 +140,12 @@ The response follows the [standard format](#response-formatting), with a success
**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](concept-freeze.html) or authorized.
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
* `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.
{% include '_snippets/rippled-api-links.md' %}

12
content/references/rippled-api/public-rippled-methods/account-methods/account_info.md
View File

@@ -1,9 +1,9 @@
## account_info
# account_info
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/AccountInfo.cpp "Source")
The `account_info` command retrieves information about an account, its activity, and its XRP balance. All information retrieved is relative to a particular version of the ledger.
#### Request Format
## Request Format
An example of an account_info request:
@@ -62,7 +62,7 @@ The request contains the following parameters:
The following fields are deprecated and should not be provided: `ident`, `ledger`.
#### Response Format
## Response Format
An example of a successful response:
@@ -200,9 +200,13 @@ Each object in the `transactions` array, if present, may contain any or all of t
| `max_spend_drops` | String | The maximum amount of XRP, [in drops](#specifying-currency-amounts), this transaction could send or destroy. |
| `seq` | Integer | The [Sequence Number][] of this transaction. |
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing. For example, the request specified `queue` as `true` but specified a `ledger_index` that is not the current open ledger.
* `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.
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

12
content/references/rippled-api/public-rippled-methods/account-methods/account_lines.md
View File

@@ -1,9 +1,9 @@
## account_lines
# account_lines
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/AccountLines.cpp "Source")
The `account_lines` method returns information about an account's trust lines, including balances in all non-XRP currencies and assets. All information retrieved is relative to a particular version of the ledger.
#### Request Format
## Request Format
An example of the request format:
@@ -51,7 +51,7 @@ The request accepts the following paramters:
The following parameters are deprecated and may be removed without further notice: `ledger` and `peer_index`.
#### Response Format
## Response Format
An example of a successful response:
@@ -177,10 +177,14 @@ Each trust line object has some combination of the following fields:
| `freeze` | Boolean | (May be omitted) `true` if this account has [frozen](concept-freeze.html) this trust line. If omitted, that is the same as `false`. |
| `freeze_peer` | Boolean | (May be omitted) `true` if the peer account has [frozen](concept-freeze.html) this trust line. If omitted, that is the same as `false`. |
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
* `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.
* `actMalformed` - If the `marker` field provided is not acceptable.
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

12
content/references/rippled-api/public-rippled-methods/account-methods/account_objects.md
View File

@@ -1,4 +1,4 @@
## account_objects
# 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.
@@ -15,7 +15,7 @@ The types of objects that may appear in the `account_objects` response for an ac
- [Check objects](reference-ledger-format.html#check) for pending checks.
#### Request Format
## Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
@@ -70,7 +70,7 @@ The request includes the following parameters:
| `limit` | Unsigned Integer | _(Optional)_ The maximum number of objects to include in the results. Must be within the inclusive range 10 to 400 on non-admin connections. Defaults to 200. |
| `marker` | [(Not Specified)](#markers-and-pagination) | _(Optional)_ Value from a previous paginated response. Resume retrieving data where that response left off. |
#### Response Format
## Response Format
An example of a successful response:
@@ -610,9 +610,13 @@ The response follows the [standard format](#response-formatting), with a success
| `marker` | [(Not Specified)](#markers-and-pagination) | Server-defined value indicating the response is paginated. Pass this to the next call to resume where this call left off. Omitted when there are no additional pages after this one. |
| `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. |
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
* `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.
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

12
content/references/rippled-api/public-rippled-methods/account-methods/account_offers.md
View File

@@ -1,9 +1,9 @@
## account_offers
# account_offers
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/AccountOffers.cpp "Source")
The `account_offers` method retrieves a list of offers made by a given account that are outstanding as of a particular ledger version.
#### Request Format
## Request Format
An example of the request format:
@@ -58,7 +58,7 @@ A request can include the following parameters:
The following parameter is deprecated and may be removed without further notice: `ledger`.
#### Response Format
## Response Format
An example of a successful response:
@@ -178,10 +178,14 @@ Each offer object contains the following fields:
| `quality` | String | The exchange rate of the offer, as the ratio of the original `taker_pays` divided by the original `taker_gets`. When executing offers, the offer with the most favorable (lowest) quality is consumed first; offers with the same quality are executed from oldest to newest. [New in: rippled 0.29.0][] |
| `expiration` | Unsigned integer | (May be omitted) A time after which this offer is considered unfunded, as [the number of seconds since the Ripple Epoch](#specifying-time). See also: [Offer Expiration](reference-transaction-format.html#expiration). [New in: rippled 0.30.1][] |
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
* `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.
* `actMalformed` - If the `marker` field provided is not acceptable.
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

16
content/references/rippled-api/public-rippled-methods/account-methods/account_tx.md
View File

@@ -1,9 +1,9 @@
## account_tx
# account_tx
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/AccountTx.cpp "Source")
The `account_tx` method retrieves a list of transactions that involved the specified account.
#### Request Format
## Request Format
An example of the request format:
@@ -73,13 +73,13 @@ While each of these fields is marked as optional, **you must use at least one**
**Note:** For WebSocket and JSON-RPC, there is also a deprecated legacy variation of the `account_tx` method. For that reason, Ripple recommends *not using any of the following fields*: `offset`, `count`, `descending`, `ledger_max`, and `ledger_min`. If you use any of these deprecated fields, the method does not support pagination.
##### **Iterating over queried data**
### Iterating over queried data
As with other paginated methods, you can use the `marker` field to return multiple pages of data.
In the time between requests, `"ledger_index_min": -1` and `"ledger_index_max": -1` may change to refer to different ledger versions than they did before. The `marker` field can safely paginate even if there are changes in the ledger range from the request, so long as the marker does not indicate a point outside the range of ledgers specified in the request.
#### Response Format
## Response Format
An example of a successful response:
@@ -581,11 +581,15 @@ Each transaction object includes the following fields, depending on whether it w
| `tx` | Object | (JSON mode only) JSON object defining the transaction |
| `tx_blob` | String | (Binary mode only) Unique hashed String representing the transaction. |
| `validated` | Boolean | Whether or not the transaction is included in a validated ledger. Any transaction not yet in a validated ledger is subject to change. |
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
* `actMalformed` - The [Address][] specified in the `account` field of the request is not formatted properly.
* `actBitcoin` - The [Address][] specified in the `account` field is formatted like a Bitcoin address instead of a XRP Ledger address.
* `lgrIdxsInvalid` - The ledger specified by the `ledger_index_min` or `ledger_index_max` does not exist, or if it does exist but the server does not have it.
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

12
content/references/rippled-api/public-rippled-methods/account-methods/gateway_balances.md
View File

@@ -1,9 +1,9 @@
## gateway_balances
# gateway_balances
[[Source]<br>](https://github.com/ripple/rippled/blob/9111ad1a9dc37d49d085aa317712625e635197c0/src/ripple/rpc/handlers/GatewayBalances.cpp "Source")
The `gateway_balances` command calculates the total balances issued by a given account, optionally excluding amounts held by [operational addresses](concept-issuing-and-operational-addresses.html). [New in: rippled 0.28.2][]
#### Request Format
## Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
@@ -52,7 +52,7 @@ The request includes the following parameters:
| `ledger_hash` | String | _(Optional)_ A 20-byte hex string for the ledger version to use. (See [Specifying a Ledger](#specifying-ledgers)) |
| `ledger_index` | String or Unsigned Integer | _(Optional)_ The sequence number of the ledger version to use, or a shortcut string to choose a ledger automatically. (See [Specifying a Ledger](#specifying-ledgers)) |
#### Response Format
## Response Format
An example of a successful response:
@@ -209,10 +209,14 @@ The response follows the [standard format](#response-formatting), with a success
| `ledger_index` | Number | (May be omitted) The sequence number of the ledger version that was used to generate this response. |
| `ledger_current_index` | Number | (May be omitted) The sequence number of the current in-progress ledger version that was used to generate this response. |
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
* `invalidHotWallet` - One or more of the addresses specified in the `hotwallet` field is not the [Address][] of an account holding currency issued by the account from the request.
* `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.
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

12
content/references/rippled-api/public-rippled-methods/account-methods/noripple_check.md
View File

@@ -1,9 +1,9 @@
## noripple_check
# noripple_check
[[Source]<br>](https://github.com/ripple/rippled/blob/9111ad1a9dc37d49d085aa317712625e635197c0/src/ripple/rpc/handlers/NoRippleCheck.cpp "Source")
The `noripple_check` command provides a quick way to check the status of [the DefaultRipple field for an account and the NoRipple flag of its trust lines](concept-noripple.html), compared with the recommended settings.
#### Request Format
## Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
@@ -54,7 +54,7 @@ The request includes the following parameters:
| `ledger_hash` | String | _(Optional)_ A 20-byte hex string for the ledger version to use. (See [Specifying a Ledger](#specifying-ledgers)) |
| `ledger_index` | String or Unsigned Integer | _(Optional)_ The sequence number of the ledger to use, or a shortcut string to choose a ledger automatically. (See [Specifying a Ledger](#specifying-ledgers)) |
#### Response Format
## Response Format
An example of a successful response:
@@ -173,9 +173,13 @@ The response follows the [standard format](#response-formatting), with a success
| `problems` | Array | Array of strings with human-readable descriptions of the problems. This includes up to one entry if the account's DefaultRipple setting is not as recommended, plus up to `limit` entries for trust lines whose NoRipple setting is not as recommended. |
| `transactions` | Array | (May be omitted) If the request specified `transactions` as `true`, this is an array of JSON objects, each of which is the JSON form of a [transaction](reference-transaction-format.html) that should fix one of the described problems. The length of this array is the same as the `problems` array, and each entry is intended to fix the problem described at the same index into that array. |
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
* `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.
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

14
content/references/rippled-api/public-rippled-methods/ledger-methods/ledger.md
View File

@@ -1,9 +1,9 @@
## ledger
# ledger
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/LedgerHandler.cpp "Source")
Retrieve information about the public ledger.
#### Request Format
## Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
@@ -70,7 +70,7 @@ The request can contain the following parameters:
The `ledger` field is deprecated and may be removed without further notice.
#### Response Format
## Response Format
An example of a successful response:
@@ -188,9 +188,15 @@ If the request specified `"owner_funds": true` and expanded transactions, the re
|:--------------|:-------|:----------------------------------------------------|
| `owner_funds` | String | Numeric amount of the `TakerGets` currency that the `Account` sending this OfferCreate transaction has after the execution of all transactions in this ledger. This does not check whether the currency amount is [frozen](concept-freeze.html). |
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
* `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.
* `noPermission` - If you specified `full` or `accounts` as true, but are not connected to the server as an admin (usually, admin requires connecting on a local port).
<!-- TODO: we should add this fee levels link to rippled-api-links.md. server_state.md is also including this as a one-off.-->
[fee levels]: concept-transaction-cost.html#fee-levels
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

12
content/references/rippled-api/public-rippled-methods/ledger-methods/ledger_closed.md
View File

@@ -1,9 +1,9 @@
## ledger_closed
# ledger_closed
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/LedgerClosed.cpp "Source")
The `ledger_closed` method returns the unique identifiers of the most recently closed ledger. (This ledger is not necessarily validated and immutable yet.)
#### Request Format
## Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
@@ -41,7 +41,7 @@ rippled ledger_closed
This method accepts no parameters.
#### Response Format
## Response Format
An example of a successful response:
<!-- MULTICODE_BLOCK_START -->
@@ -82,6 +82,10 @@ The response follows the [standard format](#response-formatting), with a success
| `ledger_hash` | String | 20-byte hex string with a unique hash of the ledger |
| `ledger_index` | Unsigned Integer | Sequence number of this ledger |
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

12
content/references/rippled-api/public-rippled-methods/ledger-methods/ledger_current.md
View File

@@ -1,9 +1,9 @@
## ledger_current
# ledger_current
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/LedgerCurrent.cpp "Source")
The `ledger_current` method returns the unique identifiers of the current in-progress ledger. This command is mostly useful for testing, because the ledger returned is still in flux.
#### Request Format
## Request Format
An example of the request format:
@@ -43,7 +43,7 @@ rippled ledger_current
The request contains no parameters.
#### Response Format
## Response Format
An example of a successful response:
<!-- MULTICODE_BLOCK_START -->
@@ -83,6 +83,10 @@ The response follows the [standard format](#response-formatting), with a success
A `ledger_hash` field is not provided, because the hash of the current ledger is constantly changing along with its contents.
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

12
content/references/rippled-api/public-rippled-methods/ledger-methods/ledger_data.md
View File

@@ -1,9 +1,9 @@
## ledger_data
# ledger_data
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/LedgerData.cpp "Source")
The `ledger_data` method retrieves contents of the specified ledger. You can iterate through several calls to retrieve the entire contents of a single ledger version.
#### Request Format
## Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
@@ -52,7 +52,7 @@ A request can include the following fields:
The `ledger` field is deprecated and may be removed without further notice.
#### Response Format
## Response Format
An example of a successful response:
@@ -250,8 +250,12 @@ The format of each object in the `state` array depends on whether `binary` was s
| (Additional fields) | (Various) | (Only included if `"binary":false`) Additional fields describing this object, depending on which LedgerEntryType it is. |
| `index` | String | Unique identifier for this ledger entry, as hex. |
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors)
* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
* `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.
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

14
content/references/rippled-api/public-rippled-methods/ledger-methods/ledger_entry.md
View File

@@ -1,11 +1,11 @@
## ledger_entry
# ledger_entry
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/LedgerEntry.cpp "Source")
The `ledger_entry` method returns a single ledger object from the XRP Ledger in its raw format. See [ledger format][] for information on the different types of objects you can retrieve.
**Note:** There is no commandline version of this method. You can use the [`json` command](#json) to access this method from the commandline instead.
#### Request Format
## Request Format
An example of the request format:
@@ -74,7 +74,7 @@ The full list of parameters recognized by this method is as follows:
The `generator` and `ledger` parameters are deprecated and may be removed without further notice.
#### Response Format
## Response Format
An example of a successful response:
@@ -140,8 +140,14 @@ The response follows the [standard format](#response-formatting), with a success
| `node` | Object | (Omitted if `"binary": true` specified.) Object containing the data of this ledger object, according to the [ledger format][]. |
| `node_binary` | String | (Omitted unless `"binary":true` specified) Binary data of the ledger object, as hex. |
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
* `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.
<!-- 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
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

12
content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/book_offers.md
View File

@@ -1,9 +1,9 @@
## book_offers
# book_offers
[[Source]<br>](https://github.com/ripple/rippled/blob/develop/src/ripple/rpc/handlers/BookOffers.cpp "Source")
The `book_offers` method retrieves a list of offers, also known as the [order book](http://www.investopedia.com/terms/o/order-book.asp), between two currencies. If the results are very large, a partial result is returned with a marker so that later requests can resume from where the previous one left off.
#### Request Format
## Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
@@ -70,7 +70,7 @@ The request includes the following parameters:
| `taker_gets` | Object | Specification of which currency the account taking the offer would receive, as an object with `currency` and `issuer` fields (omit issuer for XRP), like [currency amounts](#specifying-currency-amounts). |
| `taker_pays` | Object | Specification of which currency the account taking the offer would pay, as an object with `currency` and `issuer` fields (omit issuer for XRP), like [currency amounts](#specifying-currency-amounts). |
#### Response Format
## Response Format
An example of a successful response:
@@ -172,7 +172,7 @@ In addition to the standard Offer fields, the following fields may be included i
| `taker_pays_funded` | String (XRP) or Object (non-XRP) | (Only included in partially-funded offers) The maximum amount of currency that the taker would pay, given the funding status of the offer. |
| `quality` | Number | The exchange rate, as the ratio `taker_pays` divided by `taker_gets`. For fairness, offers that have the same quality are automatically taken first-in, first-out. (In other words, if multiple people offer to exchange currency at the same rate, the oldest offer is taken first.) |
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
@@ -182,3 +182,7 @@ In addition to the standard Offer fields, the following fields may be included i
* `srcIsrMalformed` - The `issuer` field of the `taker_pays` field in the request is not valid.
* `dstIsrMalformed` - The `issuer` field of the `taker_gets` field in the request is not valid.
* `badMarket` - The desired order book does not exist; for example, offers to exchange a currency for itself.
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

32
content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/path_find.md
View File

@@ -1,4 +1,4 @@
## path_find
# path_find
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/PathFind.cpp "Source")
*WebSocket API only!* The `path_find` method searches for a [path](concept-paths.html) along which a transaction can possibly be made, and periodically sends updates when the path changes over time. For a simpler version that is supported by JSON-RPC, see [`ripple_path_find`](#ripple-path-find). For payments occurring strictly in XRP, it is not necessary to find a path, because XRP can be sent directly to any account.
@@ -11,14 +11,14 @@ There are three different modes, or sub-commands, of the path_find command. Spec
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. Due to server load, pathfinding may not find the best results. Additionally, you should 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. 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. (**Note:** A server returning less-than-optimal results is not necessarily proof of malicious behavior; it could also be a symptom of heavy server load.)
### path_find create
## path_find create
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/PathFind.cpp#L38 "Source")
The `create` subcommand of `path_find` creates an ongoing request to find possible paths along which a payment transaction could be made from one specified account such that another account receives a desired amount of some currency. The initial response contains a suggested path between the two addresses that would result in the desired amount being received. After that, the server sends additional messages, with `"type": "path_find"`, with updates to the potential paths. The frequency of updates is left to the discretion of the server, but it usually means once every few seconds when there is a new ledger version.
A client can only have one pathfinding request open at a time. If another pathfinding request is already open on the same connection, the old request is automatically closed and replaced with the new request.
#### Request Format
### Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
@@ -57,7 +57,7 @@ The request includes the following parameters:
The server also recognizes the following fields, but the results of using them are not guaranteed: `source_currencies`, `bridges`. These fields should be considered reserved for future use.
#### Response Format
### Response Format
An example of a successful response:
@@ -451,13 +451,13 @@ Each element in the `alternatives` array is an object that represents a path fro
| `paths_computed` | Array | Array of arrays of objects defining [payment paths](concept-paths.html) |
| `source_amount` | String or Object | [Currency amount](#specifying-currency-amounts) that the source would have to send along this path for the destination to receive the desired amount |
#### Possible Errors
### Possible Errors
* Any of the [universal error types](#universal-errors).
* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
* `noEvents` - You are using a protocol that does not support asynchronous callbacks, for example JSON-RPC. (See [ripple\_path\_find](#ripple-path-find) for a pathfinding method that _is_ compatible with JSON-RPC.)
#### Asynchronous Follow-ups
### Asynchronous Follow-ups
In addition to the initial response, the server sends more messages in a similar format to update on the status of [payment paths](concept-paths.html) over time. These messages include the `id` of the original WebSocket request so you can tell which request prompted them, and the field `"type": "path_find"` at the top level to indicate that they are additional responses. The other fields are defined in the same way as the initial response.
@@ -488,12 +488,12 @@ Here is an example of an asychronous follow-up from a path_find create request:
<!-- MULTICODE_BLOCK_END -->
### path_find close
## path_find close
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/PathFind.cpp#L46 "Source")
The `close` subcommand of `path_find` instructs the server to stop sending information about the current open pathfinding request.
#### Request Format
### Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
@@ -516,7 +516,7 @@ The request includes the following parameters:
|:-------------|:-------|:-------------------------------------------|
| `subcommand` | String | Use `"close"` to send the close subcommand |
#### Response Format
### Response Format
If a pathfinding request was successfully closed, the response follows the same format as the initial response to [`path_find create`](#path-find-create), plus the following field:
@@ -526,19 +526,19 @@ If a pathfinding request was successfully closed, the response follows the same
If there was no outstanding pathfinding request, an error is returned instead.
#### Possible Errors
### Possible Errors
* Any of the [universal error types](#universal-errors).
* `invalidParams` - If any fields are specified incorrectly, or any required fields are missing.
* `noEvents` - If you tried to use this method on a protocol that does not support asynchronous callbacks, for example JSON-RPC. (See [ripple\_path\_find](#ripple-path-find) for a pathfinding method that _is_ compatible with JSON-RPC.)
* `noPathRequest` - You tried to close a pathfinding request when there is not an open one.
### path_find status
## path_find status
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/PathFind.cpp#L57 "Source")
The `status` subcommand of `path_find` requests an immediate update about the client's currently-open pathfinding request.
#### Request Format
### Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
@@ -561,7 +561,7 @@ The request includes the following parameters:
|:-------------|:-------|:---------------------------------------------|
| `subcommand` | String | Use `"status"` to send the status subcommand |
#### Response Format
### Response Format
If a pathfinding request is open, the response follows the same format as the initial response to [`path_find create`](#path-find-create), plus the following field:
@@ -571,9 +571,13 @@ If a pathfinding request is open, the response follows the same format as the in
If there was no outstanding pathfinding request, an error is returned instead.
#### Possible Errors
### Possible Errors
* Any of the [universal error types](#universal-errors).
* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
* `noEvents` - You are using a protocol that does not support asynchronous callbacks, for example JSON-RPC. (See [ripple\_path\_find](#ripple-path-find) for a pathfinding method that _is_ compatible with JSON-RPC.)
* `noPathRequest` - You tried to check the status of a pathfinding request when there is not an open one.
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

12
content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/ripple_path_find.md
View File

@@ -1,4 +1,4 @@
## ripple_path_find
# 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](concept-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.
@@ -7,7 +7,7 @@ Although the `rippled` server tries to find the cheapest path or combination of
**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.
#### Request Format
## Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
@@ -86,7 +86,7 @@ The request includes the following parameters:
| `ledger_hash` | String | _(Optional)_ A 20-byte hex string for the ledger version to use. (See [Specifying a Ledger](#specifying-ledgers)) |
| `ledger_index` | String or Unsigned Integer | _(Optional)_ The sequence number of the ledger to use, or a shortcut string to choose a ledger automatically. (See [Specifying a Ledger](#specifying-ledgers)) |
#### Response Format
## Response Format
An example of a successful response:
@@ -328,7 +328,7 @@ Each element in the `alternatives` array is an object that represents a path fro
The following fields are deprecated, and may be omitted: `paths_canonical`, and `paths_expanded`. If they appear, you should disregard them.
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
* `tooBusy` - The server is under too much load to calculate paths. Not returned if you are connected as an admin.
@@ -339,3 +339,7 @@ The following fields are deprecated, and may be omitted: `paths_canonical`, and
* `dstActMalformed` - The `destination_account` field in the request is not formatted properly.
* `srcCurMalformed` - The `source_currencies` field is not formatted properly.
* `srcIsrMalformed` - The `issuer` field of one or more of the currency objects in the request is not valid.
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

13
content/references/rippled-api/public-rippled-methods/payment-channel-methods/channel_authorize.md
View File

@@ -1,11 +1,11 @@
## channel_authorize
# channel_authorize
[[Source]<br>](https://github.com/ripple/rippled/blob/d4a56f223a3b80f64ff70b4e90ab6792806929ca/src/ripple/rpc/handlers/PayChanClaim.cpp#L41 "Source")
_(Requires the [PayChan amendment](reference-amendments.html#paychan) to be enabled. [New in: rippled 0.33.0][])_
The `channel_authorize` method creates a signature that can be used to redeem a specific amount of XRP from a payment channel.
#### Request Format
## Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
@@ -57,7 +57,7 @@ The request includes the following parameters:
**Note:** You cannot use Ed25519 keys to sign claims with this method. This is a known bug (RIPD-1474).
#### Response Format
## Response Format
An example of a successful response:
@@ -107,9 +107,14 @@ The response follows the [standard format](#response-formatting), with a success
|-------|------|-------------|
| `signature` | String | The signature for this claim, as a hexadecimal value. To process the claim, the destination account of the payment channel must send a [PaymentChannelClaim transaction][] with this signature, the exact Channel ID, XRP amount, and public key of the channel. |
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
* `badSeed` - The `secret` in the request is not a valid secret key.
* `channelAmtMalformed` - The `amount` in the request is not a valid [XRP amount](#specifying-currency-amounts).
* `channelMalformed` - The `channel_id` in the request is not a valid Channel ID. The Channel ID should be a 256-bit (64-character) hexadecimal string.
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}

12
content/references/rippled-api/public-rippled-methods/payment-channel-methods/channel_verify.md
View File

@@ -1,11 +1,11 @@
## channel_verify
# channel_verify
[[Source]<br>](https://github.com/ripple/rippled/blob/d4a56f223a3b80f64ff70b4e90ab6792806929ca/src/ripple/rpc/handlers/PayChanClaim.cpp#L89 "Source")
_(Requires the [PayChan amendment](reference-amendments.html#paychan) to be enabled. [New in: rippled 0.33.0][])_
The `channel_verify` method checks the validity of a signature that can be used to redeem a specific amount of XRP from a payment channel.
#### Request Format
## Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
@@ -58,7 +58,7 @@ The request includes the following parameters:
| `public_key` | String | The public key of the channel and the key pair that was used to create the signature, in hexadecimal or base58 format. [Updated in: rippled 0.90.0][New in: rippled 0.90.0] |
| `signature` | String | The signature to verify, in hexadecimal. |
#### Response Format
## Response Format
An example of a successful response:
@@ -111,10 +111,14 @@ The response follows the [standard format](#response-formatting), with a success
**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](#account-channels).
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
* `publicMalformed` - The `public_key` field of the request is not a valid public key in the correct format. Public keys are 33 bytes and must be represented in base58 or hexadecimal. The base58 representation of account public keys starts with the letter `a`. The hexadecimal representation is 66 characters long.
* `channelMalformed` - The `channel_id` field of the request is not a valid Channel ID. The Channel ID must be a 256-bit (64-character) hexadecimal string.
* `channelAmtMalformed` - The value specified in the `amount` field was not a valid [XRP amount](#specifying-currency-amounts).
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

14
content/references/rippled-api/public-rippled-methods/server-info-methods/fee.md
View File

@@ -1,11 +1,11 @@
## fee
# fee
[[Source]<br>](https://github.com/ripple/rippled/blob/release/src/ripple/rpc/handlers/Fee1.cpp "Source")
The `fee` command reports the current state of the open-ledger requirements for the [transaction cost](concept-transaction-cost.html). This requires the [FeeEscalation amendment](reference-amendments.html#feeescalation) to be enabled. [New in: rippled 0.31.0][]
This is a public command available to unprivileged users. [Updated in: rippled 0.32.0][New in: rippled 0.32.0]
#### Request Format
## Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
@@ -39,7 +39,7 @@ rippled fee
The request does not include any parameters.
#### Response Format
## Response Format
An example of a successful response:
@@ -153,6 +153,12 @@ The response follows the [standard format](#response-formatting), with a success
| `levels.reference_level` | String (Integer) | The equivalent of the minimum transaction cost, represented in [fee levels][]. |
| `max_queue_size` | String (Integer) | The maximum number of transactions that the [transaction queue](concept-transaction-cost.html#queued-transactions) can currently hold. |
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
<!-- TODO: fee levels link to rippled-api-links.md - it is being used one off in a couple of files -->
[fee levels]: concept-transaction-cost.html#fee-levels
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

12
content/references/rippled-api/public-rippled-methods/server-info-methods/server_info.md
View File

@@ -1,9 +1,9 @@
## server_info
# server_info
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/ServerInfo.cpp "Source")
The `server_info` command asks the server for a human-readable version of various information about the `rippled` server being queried.
#### Request Format
## Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
@@ -41,7 +41,7 @@ rippled server_info
The request does not take any parameters.
#### Response Format
## Response Format
An example of a successful response:
@@ -319,6 +319,10 @@ The `info` object may have some arrangement of the following fields:
[transaction cost]: concept-transaction-cost.html
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

16
content/references/rippled-api/public-rippled-methods/server-info-methods/server_state.md
View File

@@ -1,9 +1,9 @@
## server_state
# server_state
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/ServerState.cpp "Source")
The `server_state` command asks the server for various machine-readable information about the `rippled` server's current state. The results are almost the same as [`server_info`](#server-info), but using units that are easier to process instead of easier to read. (For example, XRP values are given in integer drops instead of scientific notation or decimal values, and time is given in milliseconds instead of seconds.)
#### Request Format
## Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
@@ -41,7 +41,7 @@ rippled server_state
The request does not takes any parameters.
#### Response Format
## Response Format
An example of a successful response:
@@ -282,8 +282,14 @@ The `state` object may have some arrangement of the following fields:
| `validation_quorum` | Number | Minimum number of trusted validations required to validate a ledger version. Some circumstances may cause the server to require more validations. |
| `validator_list_expires` | Number | _(Admin only)_ When the current validator list will expire, in seconds since the [Ripple Epoch](#specifying-time), or 0 if the server has yet to load a published validator list. [New in: rippled 0.80.1][] |
[fee levels]: concept-transaction-cost.html#fee-levels
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
<!-- TODO: add fee levels and transaction cost to rippled-api-links.md. multiple files are including them one-off, as below -->
[fee levels]: concept-transaction-cost.html#fee-levels
[transaction cost]: concept-transaction-cost.html
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}

25
content/references/rippled-api/public-rippled-methods/subscription-methods/subscribe.md
View File

@@ -1,9 +1,9 @@
## subscribe
# subscribe
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/Subscribe.cpp "Source")
The `subscribe` method requests periodic notifications from the server when certain events happen.
#### Request Format
## Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
@@ -87,7 +87,7 @@ Each member of the `books` array, if provided, is an object with the following f
| `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. |
#### Response Format
## Response Format
An example of a successful response:
@@ -114,7 +114,7 @@ The response follows the [standard format](#response-formatting). The fields con
* *Stream: ledger* - Information about the ledgers on hand and current fee schedule, such as `fee_base` (current base fee for transactions in XRP), `fee_ref` (current base fee for transactions in fee units), `ledger_hash` (hash of the latest validated ledger), `reserve_base` (minimum reserve for accounts), and more.
* `books` - No fields returned by default. If `"snapshot": true` is set in the request, returns `offers` (an array of offer definition objects defining the order book)
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
@@ -130,7 +130,7 @@ The response follows the [standard format](#response-formatting). The fields con
When you subscribe to a particular stream, you receive periodic responses on that stream until you unsubscribe or close the WebSocket connection. The content of those responses depends on what you subscribed to. Here are some examples:
### Ledger Stream
## Ledger Stream
The `ledger` stream only sends `ledgerClosed` messages when [the consensus process](https://ripple.com/build/ripple-ledger-consensus-process/) declares a new validated ledger. The message identifies the ledger and provides some information about its contents.
@@ -165,7 +165,7 @@ The fields from a ledger stream message are as follows:
| `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. |
### Validations Stream
## Validations Stream
[New in: rippled 0.29.0][]
@@ -214,8 +214,7 @@ The fields from a validations stream message are as follows:
| `validation_public_key` | String | The [base58][] encoded public key from the key-pair that the validator used to sign the message. This identifies the validator sending the message and can also be used to verify the `signature`. |
### Transaction Streams
## Transaction Streams
Many subscriptions result in messages about transactions, including the following:
@@ -353,7 +352,7 @@ Transaction stream messages have the following fields:
| `validated` | Boolean | If true, this transaction is included in a validated ledger. Responses from the `transaction` stream should always be validated. |
### Peer Status Stream
## Peer Status Stream
The admin-only `peer_status` stream reports a large amount of information on the activities of other `rippled` servers to which this server is connected, in particular their status in the consensus process.
@@ -383,7 +382,7 @@ Peer Status stream messages represent some event where the status of the peer `r
| `ledger_index_max` | Number | (May be omitted) The largest [Ledger Index][] the peer has currently available. |
| `ledger_index_min` | Number | (May be omitted) The smallest [Ledger Index][] the peer has currently available. |
#### Peer Status Events
### Peer Status Events
The `action` field of a Peer Status stream message can have the following values:
@@ -395,7 +394,7 @@ The `action` field of a Peer Status stream message can have the following values
| `LOST_SYNC` | The peer fell behind the rest of the network in tracking which ledger versions are validated and which are undergoing consensus. |
### Order Book Streams
## Order Book Streams
When you subscribe to one or more order books with the `books` field, you get back any transactions that affect those order books.
@@ -531,3 +530,7 @@ The format of an order book stream message is the same as that of [transaction s
| `Field` | Value | Description |
|:--------------------------|:-------|:----------------------------------------|
| `transaction.owner_funds` | String | Numeric amount of the `TakerGets` currency that the `Account` sending this OfferCreate transaction has after executing this transaction. This does not check whether the currency amount is [frozen](concept-freeze.html). |
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

12
content/references/rippled-api/public-rippled-methods/subscription-methods/unsubscribe.md
View File

@@ -1,9 +1,9 @@
## unsubscribe
# unsubscribe
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/Unsubscribe.cpp "Source")
The `unsubscribe` command tells the server to stop sending messages for a particular subscription or set of subscriptions.
#### Request Format
## Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
@@ -55,7 +55,7 @@ The objects in the `books` array are defined almost like the ones from subscribe
| `taker_pays` | Object | Specification of which currency the account taking the offer would pay, as an object with `currency` and `issuer` fields (omit issuer for XRP), like [currency amounts](#specifying-currency-amounts). |
| `both` | Boolean | (Optional, defaults to false) If true, remove a subscription for both sides of the order book. |
#### Response Format
## Response Format
An example of a successful response:
@@ -76,7 +76,7 @@ An example of a successful response:
The response follows the [standard format](#response-formatting), with a successful result containing no fields.
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
@@ -89,3 +89,7 @@ The response follows the [standard format](#response-formatting), with a success
* `srcIsrMalformed` - The `issuer` field of one or more `taker_pays` sub-fields of the `books` field in the request is not valid.
* `dstIsrMalformed` - The `issuer` field of one or more `taker_gets` sub-fields of the `books` field in the request is not valid.
* `badMarket` - One or more desired order books in the `books` field does not exist; for example, offers to exchange a currency for itself.
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

12
content/references/rippled-api/public-rippled-methods/transaction-methods/sign.md
View File

@@ -1,11 +1,11 @@
## sign
# sign
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/SignHandler.cpp "Source")
The `sign` method takes a [transaction in JSON format](reference-transaction-format.html) and a secret key, and returns a signed binary representation of the transaction. The result is always different, even when you provide the same transaction JSON and secret key. To contribute one signature to a multi-signed transaction, use the [`sign_for` command](#sign-for) instead.
**Caution:** Unless you run the `rippled` server yourself, you should do [local signing with RippleAPI](reference-rippleapi.html#sign) instead of using this command. An untrustworthy server could change the transaction before signing it, or use your secret key to sign additional arbitrary transactions as if they came from you.
#### Request Format
## Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
@@ -100,7 +100,7 @@ The server automatically tries to fill in certain fields in `tx_json` (the [Tran
* **Caution:** A malicious server can specify an excessively high transaction cost, ignoring the values of `fee_mult_max` and `fee_div_max`.
* `Paths` - For Payment-type transactions (excluding XRP-to-XRP transfers), the Paths field can be automatically filled, as if you did a [ripple_path_find](#ripple-path-find). Only filled if `build_path` is provided.
#### Response Format
## Response Format
An example of a successful response:
@@ -207,10 +207,14 @@ The response follows the [standard format](#response-formatting), with a success
* Do not paste this error to a public place for debugging.
* Do not display the error message on a website, even by accident.
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
* `highFee` - The current load-based multiplier to the transaction cost exceeds the limit for an automatically-provided transaction cost. Either specify a higher `fee_mult_max` (at least 1000) in the request or manually provide a value in the `Fee` field of the `tx_json`.
* `tooBusy` - The transaction did not include paths, but the server is too busy to do pathfinding right now. Does not occur if you are connected as an admin.
* `noPath` - The transaction did not include paths, and the server was unable to find a path by which this payment can occur.
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

12
content/references/rippled-api/public-rippled-methods/transaction-methods/sign_for.md
View File

@@ -1,11 +1,11 @@
## sign_for
# sign_for
[[Source]<br>](https://github.com/ripple/rippled/blob/release/src/ripple/rpc/handlers/SignFor.cpp "Source")
The `sign_for` command provides one signature for a [multi-signed transaction](reference-transaction-format.html#multi-signing).
This command requires the [MultiSign amendment](reference-amendments.html#multisign) to be enabled. [New in: rippled 0.31.0][]
#### Request Format
## Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
@@ -97,7 +97,7 @@ The request includes the following parameters:
You must provide exactly 1 field with the secret key. You can use any of the following fields: `secret`, `passphrase`, `seed`, or `seed_hex`.
#### Response Format
## Response Format
An example of a successful response:
@@ -219,7 +219,7 @@ The response follows the [standard format](#response-formatting), with a success
| `tx_blob` | String | Hexadecimal representation of the signed transaction, including the newly-added signature. If it has enough signatures, you can [submit this string using the `submit` command](#submit-only-mode). |
| `tx_json` | Object | The [transaction specification](reference-transaction-format.html) in JSON format, with the newly-added signature in the `Signers` array. If it has enough signatures, you can submit this object using the [`submit_multisigned` command](#submit-multisigned). |
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
@@ -227,3 +227,7 @@ The response follows the [standard format](#response-formatting), with a success
* `srcActMalformed` - If the signing address (`account` field) from the request is not validly formed.
* `badSeed` - The seed value supplied was invalidly-formatted.
* `badSecret` - The secret value supplied was invalidly-formatted.
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

18
content/references/rippled-api/public-rippled-methods/transaction-methods/submit.md
View File

@@ -1,4 +1,4 @@
## submit
# submit
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/Submit.cpp "Source")
The `submit` method applies a [transaction](reference-transaction-format.html) and sends it to the network to be confirmed and included in future ledgers.
@@ -10,7 +10,7 @@ This command has two modes:
To send a transaction as robustly as possible, you should construct and [`sign`](#sign) it in advance, persist it somewhere that you can access even after a power outage, then `submit` it as a `tx_blob`. After submission, monitor the network with the [`tx`](#tx) command to see if the transaction was successfully applied; if a restart or other problem occurs, you can safely re-submit the `tx_blob` transaction: it won't be applied twice since it has the same sequence number as the old transaction.
### Submit-Only Mode
## Submit-Only Mode
A submit-only request includes the following parameters:
@@ -19,7 +19,7 @@ A submit-only request includes the following parameters:
| `tx_blob` | String | Hex representation of the signed transaction to submit. This can be a [multi-signed transaction](reference-transaction-format.html#multi-signing). |
| `fail_hard` | Boolean | (Optional, defaults to false) If true, and the transaction fails locally, do not retry or relay the transaction to other servers |
#### Request Format
### Request Format
<!-- MULTICODE_BLOCK_START -->
@@ -58,7 +58,7 @@ submit 1200002280000000240000000361D4838D7EA4C6800000000000000000000000000055534
[Try it! >](ripple-api-tool.html#submit)
### Sign-and-Submit Mode
## Sign-and-Submit Mode
This mode signs a transaction and immediately submits it. This mode is intended to be used for testing. You cannot use this mode for [multi-signed transactions](reference-transaction-format.html#multi-signing).
@@ -85,7 +85,7 @@ The request includes the following parameters:
See the [sign command](#sign) for detailed information on how the server automatically fills in certain fields.
#### Request Format
### Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
@@ -148,7 +148,7 @@ rippled submit s█████████████████████
[Try it! >](ripple-api-tool.html#submit)
#### Response Format
## Response Format
An example of a successful response:
@@ -269,7 +269,7 @@ The response follows the [standard format](#response-formatting), with a success
* Do not display an error message including your secret key on a website, even by accident.
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
* `amendmentBlocked` - The transaction cannot be submitted to the network because the `rippled` server is [amendment blocked](concept-amendments.html#amendment-blocked).
@@ -281,3 +281,7 @@ The response follows the [standard format](#response-formatting), with a success
* `invalidTransaction` - The transaction is malformed or otherwise invalid.
* `noPath` - The transaction did not include paths, and the server was unable to find a path by which this payment can occur. (Sign-and-Submit mode only)
* `tooBusy` - The transaction did not include paths, but the server is too busy to do pathfinding right now. Does not occur if you are connected as an admin. (Sign-and-Submit mode only)
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

12
content/references/rippled-api/public-rippled-methods/transaction-methods/submit_multisigned.md
View File

@@ -1,11 +1,11 @@
## submit_multisigned
# submit_multisigned
[[Source]<br>](https://github.com/ripple/rippled/blob/release/src/ripple/rpc/handlers/SubmitMultiSigned.cpp "Source")
The `submit_multisigned` command applies a [multi-signed](reference-transaction-format.html#multi-signing) transaction and sends it to the network to be included in future ledgers. (You can also submit multi-signed transactions in binary form using the [`submit` command in submit-only mode](#submit-only-mode).)
This command requires the [MultiSign amendment](reference-amendments.html#multisign) to be enabled. [New in: rippled 0.31.0][]
#### Request Format
## Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
@@ -133,7 +133,7 @@ The request includes the following parameters:
| `tx_json` | Object | [Transaction in JSON format](reference-transaction-format.html) with an array of `Signers`. To be successful, the weights of the signatures must be equal or higher than the quorum of the [SignerList](reference-ledger-format.html#signerlist). |
| `fail_hard` | Boolean | (Optional, defaults to false) If true, and the transaction fails locally, do not retry or relay the transaction to other servers. |
#### Response Format
## Response Format
An example of a successful response:
@@ -242,9 +242,13 @@ The response follows the [standard format](#response-formatting), with a success
| `tx_blob` | String | The complete [transaction](reference-transaction-format.html) in hex string format |
| `tx_json` | Object | The complete [transaction](reference-transaction-format.html) in JSON format |
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
* `srcActMalformed` - The `Account` field from the `tx_json` was invalid or missing.
* `internal` - An internal error occurred. This includes the case where a signature is not valid for the transaction JSON provided.
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

12
content/references/rippled-api/public-rippled-methods/transaction-methods/transaction_entry.md
View File

@@ -1,9 +1,9 @@
## transaction_entry
# transaction_entry
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/TransactionEntry.cpp "Source")
The `transaction_entry` method retrieves information on a single transaction from a specific ledger version. (The [`tx`](#tx) command, by contrast, searches all ledgers for the specified transaction. We recommend using that method instead.)
#### Request Format
## Request Format
An example of the request format:
@@ -55,7 +55,7 @@ The request includes the following parameters:
**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`.
#### Response Format
## Response Format
An example of a successful response:
@@ -208,7 +208,7 @@ There are a couple possible reasons the server may fail to find the transaction:
* The transaction exists, but not in the specified ledger version
* The server does not have the specified ledger version available. Another server that has the correct version on hand may have a different response.
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
* `fieldNotFoundTransaction` - The `tx_hash` field was omitted from the request
@@ -217,3 +217,7 @@ There are a couple possible reasons the server may fail to find the transaction:
* `transactionNotFound` - The transaction specified in the request could not be found in the specified ledger. (It might be in a different ledger version, or it might not be available at all.)
<!-- I think ledgerNotFound ( https://github.com/ripple/rippled/blob/develop/src/ripple/rpc/handlers/TransactionEntry.cpp#L62 ) should not occur because lookupLedger would have errored out first. -->
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

12
content/references/rippled-api/public-rippled-methods/transaction-methods/tx.md
View File

@@ -1,9 +1,9 @@
## tx
# tx
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/Tx.cpp "Source")
The `tx` method retrieves information on a single transaction.
#### Request Format
## Request Format
An example of the request format:
@@ -50,7 +50,7 @@ The request includes the following parameters:
| `transaction` | String | The 256-bit hash of the transaction, as hex. |
| `binary` | Boolean | (Optional, defaults to false) If true, return transaction data and metadata as hex strings instead of JSON |
#### Response Format
## Response Format
An example of a successful response:
@@ -197,8 +197,12 @@ The response follows the [standard format](#response-formatting), with a success
| `validated` | Boolean | True if this data is from a validated ledger version; if omitted or set to false, this data is not final. |
| (Various) | (Various) | Other fields from the [Transaction object](reference-transaction-format.html) |
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
* `txnNotFound` - Either the transaction does not exist, or it was part of an older ledger version that `rippled` does not have available.
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

12
content/references/rippled-api/public-rippled-methods/transaction-methods/tx_history.md
View File

@@ -1,11 +1,11 @@
## tx_history
# tx_history
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/TxHistory.cpp "Source")
The `tx_history` method retrieves some of the most recent transactions made.
**Caution:** This method is deprecated, and may be removed without further notice.
#### Request Format
## Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
@@ -50,7 +50,7 @@ The request includes the following parameters:
|:--------|:-----------------|:-------------------------------------|
| `start` | Unsigned Integer | Number of transactions to skip over. |
#### Response Format
## Response Format
An example of a successful response:
@@ -887,8 +887,12 @@ The response follows the [standard format](#response-formatting), with a success
The fields included in each transaction object vary slightly depending on the type of transaction. See [Transaction Format](reference-transaction-format.html) for details.
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
* `noPermission` - The `start` field specified was greater than 10000, but you are not connected to the server as an admin.
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

10
content/references/rippled-api/public-rippled-methods/utility-methods/json.md
View File

@@ -1,8 +1,8 @@
## json
# json
The `json` method is a proxy to running other commands, and accepts the parameters for the command as a JSON value. It is *exclusive to the Commandline client*, and intended for cases where the commandline syntax for specifying parameters is inadequate or undesirable.
#### Request Format
## Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
@@ -16,7 +16,7 @@ rippled -q json ledger_closed '{}'
<!-- MULTICODE_BLOCK_END -->
#### Response Format
## Response Format
An example of a successful response:
@@ -37,3 +37,7 @@ An example of a successful response:
<!-- MULTICODE_BLOCK_END -->
The response follows the [standard format](#response-formatting), with whichever fields are appropriate to the type of command made.
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled-api-links.md' %}

8
content/references/rippled-api/public-rippled-methods/utility-methods/ping.md
View File

@@ -1,9 +1,9 @@
## ping
# ping
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/Ping.cpp "Source")
The `ping` command returns an acknowledgement, so that clients can test the connection status and latency.
#### Request Format
## Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
@@ -41,7 +41,7 @@ rippled ping
The request includes no parameters.
#### Response Format
## Response Format
An example of a successful response:
@@ -73,6 +73,6 @@ An example of a successful response:
The response follows the [standard format](#response-formatting), with a successful result containing no fields. The client can measure the round-trip time from request to response as latency.
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).

8
content/references/rippled-api/public-rippled-methods/utility-methods/random.md
View File

@@ -1,9 +1,9 @@
## random
# random
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/Random.cpp "Source")
The `random` command provides a random number to be used as a source of entropy for random number generation by clients.
#### Request Format
## Request Format
An example of the request format:
<!-- MULTICODE_BLOCK_START -->
@@ -39,7 +39,7 @@ rippled random
The request includes no parameters.
#### Response Format
## Response Format
An example of a successful response:
@@ -78,7 +78,7 @@ The response follows the [standard format](#response-formatting), with a success
|:---------|:-------|:--------------------------|
| `random` | String | Random 256-bit hex value. |
#### Possible Errors
## Possible Errors
* Any of the [universal error types](#universal-errors).
* `internal` - Some internal error occurred, possibly relating to the random number generator.

114
content/references/rippled-api/rippled-old-monolith.md
View File

@@ -520,40 +520,6 @@ API methods for the Websocket and JSON-RPC APIs are defined by command names, an
## List of Public Commands
* [`account_currencies` - Get a list of currencies an account can send or receive](#account-currencies)
* [`account_channels` - Get a list of payment channels where the account is the source of the channel](#account-channels)
* [`account_info` - Get basic data about an account](#account-info)
* [`account_lines` - Get info about an account's trust lines](#account-lines)
* [`account_objects` - Get all ledger objects owned by an account](#account-objects)
* [`account_offers` - Get info about an account's currency exchange offers](#account-offers)
* [`account_tx` - Get info about an account's transactions](#account-tx)
* [`book_offers` - Get info about offers to exchange two currencies](#book-offers)
* [`channel_authorize` - Sign a claim for money from a payment channel](#channel-authorize)
* [`channel_verify` - Check a payment channel claim's signature](#channel-verify)
* [`fee` - Get information about transaction cost](#fee)
* [`gateway_balances` - Calculate total amounts issued by an account](#gateway-balances)
* [`ledger` - Get info about a ledger version](#ledger)
* [`ledger_closed` - Get the latest closed ledger version](#ledger-closed)
* [`ledger_current` - Get the current working ledger version](#ledger-current)
* [`ledger_data` - Get the raw contents of a ledger version](#ledger-data)
* [`ledger_entry` - Get one element from a ledger version](#ledger-entry)
* [`noripple_check` - Get recommended changes to an account's DefaultRipple and NoRipple settings](#noripple-check)
* [`path_find` - Find a path for a payment between two accounts and receive updates](#path-find)
* [`ping` - Confirm connectivity with the server](#ping)
* [`random` - Generate a random number](#random)
* [`ripple_path_find` - Find a path for payment between two accounts, once](#ripple-path-find)
* [`server_info` - Retrieve status of the server in human-readable format](#server-info)
* [`server_state` - Retrieve status of the server in machine-readable format](#server-state)
* [`sign` - Cryptographically sign a transaction](#sign)
* [`sign_for` - Contribute to a multi-signature](#sign-for)
* [`submit` - Send a transaction to the network](#submit)
* [`submit_multisigned` - Send a multi-signed transaction to the network](#submit-multisigned)
* [`subscribe` - Listen for updates about a particular subject](#subscribe)
* [`transaction_entry` - Retrieve info about a transaction from a particular ledger version](#transaction-entry)
* [`tx` - Retrieve info about a transaction from all the ledgers on hand](#tx)
* [`tx_history` - Retrieve info about all recent transactions](#tx-history)
* [`unsubscribe` - Stop listening for updates about a particular subject](#unsubscribe)
The `owner_info` command is deprecated. Use [`account_objects`](#account-objects) instead.
## List of Admin Commands
@@ -591,100 +557,32 @@ The following admin commands are deprecated and may be removed without further n
You can use the `rippled` application (as a separate instance) as a JSON-RPC client. In this mode, it has syntax for triggering most API methods with a single line from the command prompt, as described in each method. However, some methods or options don't have commandline syntax. For otherwise unsupported syntax, you can use the following method:
* [`json` - Pass JSON through the commandline](#json)
**Note:** The commandline interface is intended for administrative purposes only and is _not a supported API_.
# Account Information
An "Account" in the XRP Ledger represents a holder of XRP and a sender of transactions. Accounts can send and receive XRP and issued assets, participate in the decentralized exchange, and change their own settings. Creating an account involves generating keys and then receiving XRP from another account. For more information, see [Accounts](concept-accounts.html).
{% include 'rippled-api-methods/account_currencies.md' %}
{% include 'rippled-api-methods/account_channels.md' %}
{% include 'rippled-api-methods/account_info.md' %}
{% include 'rippled-api-methods/account_lines.md' %}
{% include 'rippled-api-methods/account_offers.md' %}
{% include 'rippled-api-methods/account_objects.md' %}
{% include 'rippled-api-methods/account_tx.md' %}
{% include 'rippled-api-methods/noripple_check.md' %}
{% include 'rippled-api-methods/gateway_balances.md' %}
For more information, see [Accounts](concept-accounts.html).
{% include 'rippled-api-methods/wallet_propose.md' %}
# Ledger Information
Each `rippled` server keeps a complete copy of the XRP Ledger's current state, which contains all the accounts, transactions, offers, and other data in the network in an optimized tree format. As transactions and offers are proposed, each server incorporates them into its current copy of the ledger, closes it periodically, and (if configured) participates in advancing the globally-validated version. After the network reaches consensus, that ledger version is validated and becomes permanently immutable. Any transactions that were not included in one ledger version become candidates to be included in the next validated version.
{% include 'rippled-api-methods/ledger.md' %}
{% include 'rippled-api-methods/ledger_closed.md' %}
{% include 'rippled-api-methods/ledger_current.md' %}
{% include 'rippled-api-methods/ledger_data.md' %}
{% include 'rippled-api-methods/ledger_entry.md' %}
{% include 'rippled-api-methods/ledger_request.md' %}
{% include 'rippled-api-methods/ledger_accept.md' %}
# Transactions
Transactions are the only thing that can modify the shared state of the XRP Ledger. All business on the XRP Ledger takes the form of transactions, which include not only payments, but also currency-exchange offers, account settings, and changes to the properties of the ledger itself (like adopting new features).
<!-- TODO: Took the main overview and put it in the blurb for the Transactions landing page. Needed to leave the content below b/c it contains links that the blurb can't handle. Need to find a home for this. -->
There are several sources of complication in transactions. Unlike traditional banking, where a trusted third party (the bank, or the [ACH](http://en.wikipedia.org/wiki/Automated_Clearing_House)) verifies the participants' identities and ensures their balances are adjusted accurately, Ripple uses cryptography and decentralized computing power to do the same thing. Sending XRP requires no third party aside from the distributed network itself. However, the XRP Ledger also supports issuing balances in any currency and trading them in a decentralized exchange. This brings far more power, but it also means that the system must account for [counterparty risk](http://en.wikipedia.org/wiki/Counterparty_risk#Counterparty_risk), currency conversions, and other issues. The XRP Ledger must be robust to keep track of which transactions have been completely validated, even when subject to hardware failures, attacks, or natural disasters.
{% include 'rippled-api-methods/tx.md' %}
{% include 'rippled-api-methods/transaction_entry.md' %}
{% include 'rippled-api-methods/tx_history.md' %}
{% include 'rippled-api-methods/path_find.md' %}
{% include 'rippled-api-methods/ripple_path_find.md' %}
{% include 'rippled-api-methods/sign.md' %}
{% include 'rippled-api-methods/sign_for.md' %}
{% include 'rippled-api-methods/submit.md' %}
{% include 'rippled-api-methods/submit_multisigned.md' %}
{% include 'rippled-api-methods/book_offers.md' %}
{% include 'rippled-api-methods/channel_authorize.md' %}
{% include 'rippled-api-methods/channel_verify.md' %}
# Subscriptions
Using subscriptions, you can have the server push updates to your client when various events happen, so that you can know and react right away. Subscriptions are only supported in the WebSocket API, where you can receive additional responses in the same channel.
JSON-RPC support for subscription callbacks is deprecated and may not work as expected.
{% include 'rippled-api-methods/subscribe.md' %}
{% include 'rippled-api-methods/unsubscribe.md' %}
# Server Information
There are also commands that retrieve information about the current state of the server. These may be useful for monitoring the health of the server, or in preparing for making other API methods. For example, you may query for the current fee schedule before sending a transaction, or you may check which ledger versions are available before digging into the ledger history for a specific record.
{% include 'rippled-api-methods/server_info.md' %}
{% include 'rippled-api-methods/server_state.md' %}
{% include 'rippled-api-methods/can_delete.md' %}
{% include 'rippled-api-methods/consensus_info.md' %}
@@ -693,8 +591,6 @@ There are also commands that retrieve information about the current state of the
{% include 'rippled-api-methods/feature.md' %}
{% include 'rippled-api-methods/fee.md' %}
{% include 'rippled-api-methods/get_counts.md' %}
{% include 'rippled-api-methods/ledger_cleaner.md' %}
@@ -720,12 +616,6 @@ There are also commands that retrieve information about the current state of the
The `rippled` server also provides a few commands purely for convenience.
{% include 'rippled-api-methods/ping.md' %}
{% include 'rippled-api-methods/random.md' %}
{% include 'rippled-api-methods/json.md' %}
{% include 'rippled-api-methods/connect.md' %}
{% include 'rippled-api-methods/stop.md' %}

58
dactyl-config.yml
View File

@@ -525,13 +525,14 @@ pages:
targets:
- local
- name: Account Methods #TODO: possible md landing content?
- name: Account Methods
html: account-methods.html
funnel: Docs
doc_type: References
supercategory: rippled API
category: Public rippled Methods
subcategory: Account Methods
blurb: An Account in the XRP Ledger represents a holder of XRP and a sender of transactions. Accounts can send and receive XRP and issued assets, participate in the decentralized exchange, and change their own settings. Creating an account involves generating keys and then receiving XRP from another account.
template: template-landing-children.html
targets:
- local
@@ -543,6 +544,7 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Account Methods
blurb: Get a list of payment channels where the account is the source of the channel.
targets:
- local
@@ -553,6 +555,7 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Account Methods
blurb: Get a list of currencies an account can send or receive.
targets:
- local
@@ -563,6 +566,7 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Account Methods
blurb: Get basic data about an account.
targets:
- local
@@ -573,6 +577,7 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Account Methods
blurb: Get info about an account's trust lines.
targets:
- local
@@ -583,6 +588,7 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Account Methods
blurb: Get all ledger objects owned by an account.
targets:
- local
@@ -593,6 +599,7 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Account Methods
blurb: Get info about an account's currency exchange offers.
targets:
- local
@@ -603,6 +610,7 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Account Methods
blurb: Get info about an account's transactions.
targets:
- local
@@ -613,6 +621,7 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Account Methods
blurb: Calculate total amounts issued by an account.
targets:
- local
@@ -623,16 +632,18 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Account Methods
blurb: Get recommended changes to an account's DefaultRipple and NoRipple settings.
targets:
- local
- name: Ledger Methods #TODO: possible md landing content?
- name: Ledger Methods
html: ledger-methods.html
funnel: Docs
doc_type: References
supercategory: rippled API
category: Public rippled Methods
subcategory: Ledger Methods
blurb: Each `rippled` server keeps a complete copy of the XRP Ledger's current state, which contains all the accounts, transactions, offers, and other data in the network in an optimized tree format. As transactions and offers are proposed, each server incorporates them into its current copy of the ledger, closes it periodically, and (if configured) participates in advancing the globally-validated version. After the network reaches consensus, that ledger version is validated and becomes permanently immutable. Any transactions that were not included in one ledger version become candidates to be included in the next validated version.
template: template-landing-children.html
targets:
- local
@@ -644,6 +655,7 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Ledger Methods
blurb: Get info about a ledger version.
targets:
- local
@@ -654,6 +666,7 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Ledger Methods
blurb: Get the latest closed ledger version.
targets:
- local
@@ -664,6 +677,7 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Ledger Methods
blurb: Get the current working ledger version.
targets:
- local
@@ -674,6 +688,7 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Ledger Methods
blurb: Get the raw contents of a ledger version.
targets:
- local
@@ -684,10 +699,11 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Ledger Methods
blurb: Get one element from a ledger version.
targets:
- local
- name: Transaction Methods #TODO: possible md landing content?
- name: Transaction Methods
html: transaction-methods.html # watch for clashes w/ this filename
funnel: Docs
doc_type: References
@@ -695,6 +711,7 @@ pages:
category: Public rippled Methods
subcategory: Transaction Methods
template: template-landing-children.html
blurb: Transactions are the only thing that can modify the shared state of the XRP Ledger. All business on the XRP Ledger takes the form of transactions, which include not only payments, but also currency-exchange offers, account settings, and changes to the properties of the ledger itself (like adopting new features).
targets:
- local
@@ -705,6 +722,7 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Transaction Methods
blurb: Cryptographically sign a transaction.
targets:
- local
@@ -715,6 +733,7 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Transaction Methods
blurb: Contribute to a multi-signature.
targets:
- local
@@ -725,6 +744,7 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Transaction Methods
blurb: Send a transaction to the network.
targets:
- local
@@ -735,6 +755,7 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Transaction Methods
blurb: Send a multi-signed transaction to the network.
targets:
- local
@@ -745,6 +766,7 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Transaction Methods
blurb: Retrieve info about a transaction from a particular ledger version.
targets:
- local
@@ -755,6 +777,7 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Transaction Methods
blurb: Retrieve info about a transaction from all the ledgers on hand.
targets:
- local
@@ -765,16 +788,18 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Transaction Methods
blurb: Retrieve info about all recent transactions.
targets:
- local
- name: Path and Order Book Methods #TODO: possible md landing content?
- name: Path and Order Book Methods
html: path-and-order-book-methods.html
funnel: Docs
doc_type: References
supercategory: rippled API
category: Public rippled Methods
subcategory: Path and Order Book Methods
blurb: In the XRP Ledger, paths define a way for payments to flow through intermediary steps on their way from sender to receiver. Paths enable cross-currency payments by connecting sender and receiver through order books.
template: template-landing-children.html
targets:
- local
@@ -786,6 +811,7 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Path and Order Book Methods
blurb: Get info about offers to exchange two currencies.
targets:
- local
@@ -796,6 +822,7 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Path and Order Book Methods
blurb: Find a path for a payment between two accounts and receive updates.
targets:
- local
@@ -806,16 +833,18 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Path and Order Book Methods
blurb: Find a path for payment between two accounts, once.
targets:
- local
- name: Payment Channel Methods #TODO: possible md landing content?
- name: Payment Channel Methods
html: payment-channel-methods.html
funnel: Docs
doc_type: References
supercategory: rippled API
category: Public rippled Methods
subcategory: Payment Channel Methods
blurb: Payment channels are a tool for facilitating repeated, unidirectional payments, or temporary credit between two parties. Learn about methods that work on payment channels.
template: template-landing-children.html
targets:
- local
@@ -827,6 +856,7 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Payment Channel Methods
blurb: Sign a claim for money from a payment channel.
targets:
- local
@@ -837,16 +867,18 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Payment Channel Methods
blurb: Check a payment channel claim's signature.
targets:
- local
- name: Subscription Methods #TODO: possible md landing content?
- name: Subscription Methods
html: subscription-methods.html
funnel: Docs
doc_type: References
supercategory: rippled API
category: Public rippled Methods
subcategory: Subscription Methods
blurb: Using subscriptions, you can have the server push updates to your client when various events happen, so that you can know and react right away. Subscriptions are only supported in the WebSocket API, where you can receive additional responses in the same channel. JSON-RPC support for subscription callbacks is deprecated and may not work as expected.
template: template-landing-children.html
targets:
- local
@@ -858,6 +890,7 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Subscription Methods
blurb: Listen for updates about a particular subject.
targets:
- local
@@ -868,16 +901,18 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Subscription Methods
blurb: Stop listening for updates about a particular subject.
targets:
- local
- name: Server Info Methods #TODO: possible md landing content?
- name: Server Info Methods
html: server-info-methods.html
funnel: Docs
doc_type: References
supercategory: rippled API
category: Public rippled Methods
subcategory: Server Info Methods
blurb: Learn about methods that enable you to retrieve information about the current state of the `rippled` server. These may be useful for monitoring the health of the server, or in preparing to make requests to other API methods.
template: template-landing-children.html
targets:
- local
@@ -889,6 +924,7 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Server Info Methods
blurb: Get information about transaction cost.
targets:
- local
@@ -899,6 +935,7 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Server Info Methods
blurb: Retrieve status of the server in human-readable format.
targets:
- local
@@ -909,16 +946,18 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Server Info Methods
blurb: Retrieve status of the server in machine-readable format.
targets:
- local
- name: Utility Methods #TODO: possible md landing content?
- name: Utility Methods
html: utility-methods.html
funnel: Docs
doc_type: References
supercategory: rippled API
category: Public rippled Methods
subcategory: Utility Methods
blurb: Learn about methods that provide convenient functions, such as ping and a random number generator.
template: template-landing-children.html
targets:
- local
@@ -930,6 +969,7 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Utility Methods
blurb: Pass JSON through the commandline.
targets:
- local
@@ -940,6 +980,7 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Utility Methods
blurb: Confirm connectivity with the server.
targets:
- local
@@ -950,6 +991,7 @@ pages:
supercategory: rippled API
category: Public rippled Methods
subcategory: Utility Methods
blurb: Generate a random number.
targets:
- local