XRPL (xrpl v1.0.0)
XRPL is a library for interacting with the XRP Ledger.
Summary
Functions
Accounts in the XRP Ledger are identified by an address in the XRP Ledger's [base58][] format. The address is derived from the account's master public key, which is in turn derived from a secret key. An address is represented as a string in JSON and has the following characteristics
The HTTP / WebSocket APIs support two formats of currency code
Perform a DELETE request.
Perform a DELETE request.
Perform a GET request.
Perform a GET request.
Perform a HEAD request.
Perform a HEAD request.
Each ledger entry has a unique ID. The ID is derived by hashing important contents of the entry, along with a namespace identifier. The ledger entry type determines the namespace identifier to use and which contents to include in the hash. This ensures every ID is unique. The hash function is SHA-512Half.
A ledger index is a 32-bit unsigned integer used to identify a ledger. The ledger index is sometimes known as the ledger's sequence number. (This is different from an account sequence.) The very first ledger was ledger index 1, and each new ledger has a ledger index that is 1 higher than the ledger index of the ledger immediately before it.
Perform a OPTIONS request.
Perform a OPTIONS request.
Perform a PATCH request.
Perform a PATCH request.
Perform a POST request.
Perform a POST request.
Perform a PUT request.
Perform a PUT request.
Perform a request.
Perform request and raise in case of error.
Perform a TRACE request.
Perform a TRACE request.
Types
option()
@type option() :: {:method, Tesla.Env.method()} | {:url, Tesla.Env.url()} | {:query, Tesla.Env.query()} | {:headers, Tesla.Env.headers()} | {:body, Tesla.Env.body()} | {:opts, Tesla.Env.opts()}
Options that may be passed to a request function. See request/2
for detailed descriptions.
Functions
account_address_regex()
Accounts in the XRP Ledger are identified by an address in the XRP Ledger's [base58][] format. The address is derived from the account's master public key, which is in turn derived from a secret key. An address is represented as a string in JSON and has the following characteristics:
Between 25 and 35 characters in length Starts with the character r Uses alphanumeric characters, excluding the number "0" capital letter "O", capital letter "I", and lowercase letter "l" Case-sensitive
Official documentation: https://xrpl.org/docs/references/protocol/data-types/basic-data-types/#addresses
currency_regex()
The HTTP / WebSocket APIs support two formats of currency code:
Standard Currency Codes: As a 3-character string such as "EUR" or "USD". Nonstandard Currency Codes: As a 160-bit hexadecimal string, such as "0158415500000000C1F76FF6ECB0BAC600000000". This is uncommon. Tokens with the same code can ripple across connected trust lines. Currency codes have no other behavior built into the XRP Ledger.
Official documentation: https://xrpl.org/docs/references/protocol/data-types/currency-formats/#currency-codes
delete(client, url, opts)
@spec delete(Tesla.Env.client(), Tesla.Env.url(), [option()]) :: Tesla.Env.result()
Perform a DELETE request.
See request/1
or request/2
for options definition.
delete("/users")
delete("/users", query: [scope: "admin"])
delete(client, "/users")
delete(client, "/users", query: [scope: "admin"])
delete(client, "/users", body: %{name: "Jon"})
delete!(client, url, opts)
@spec delete!(Tesla.Env.client(), Tesla.Env.url(), [option()]) :: Tesla.Env.t() | no_return()
Perform a DELETE request.
See request!/1
or request!/2
for options definition.
delete!("/users")
delete!("/users", query: [scope: "admin"])
delete!(client, "/users")
delete!(client, "/users", query: [scope: "admin"])
delete!(client, "/users", body: %{name: "Jon"})
get(client, url, opts)
@spec get(Tesla.Env.client(), Tesla.Env.url(), [option()]) :: Tesla.Env.result()
Perform a GET request.
See request/1
or request/2
for options definition.
get("/users")
get("/users", query: [scope: "admin"])
get(client, "/users")
get(client, "/users", query: [scope: "admin"])
get(client, "/users", body: %{name: "Jon"})
get!(client, url, opts)
@spec get!(Tesla.Env.client(), Tesla.Env.url(), [option()]) :: Tesla.Env.t() | no_return()
Perform a GET request.
See request!/1
or request!/2
for options definition.
get!("/users")
get!("/users", query: [scope: "admin"])
get!(client, "/users")
get!(client, "/users", query: [scope: "admin"])
get!(client, "/users", body: %{name: "Jon"})
head(client, url, opts)
@spec head(Tesla.Env.client(), Tesla.Env.url(), [option()]) :: Tesla.Env.result()
Perform a HEAD request.
See request/1
or request/2
for options definition.
head("/users")
head("/users", query: [scope: "admin"])
head(client, "/users")
head(client, "/users", query: [scope: "admin"])
head(client, "/users", body: %{name: "Jon"})
head!(client, url, opts)
@spec head!(Tesla.Env.client(), Tesla.Env.url(), [option()]) :: Tesla.Env.t() | no_return()
Perform a HEAD request.
See request!/1
or request!/2
for options definition.
head!("/users")
head!("/users", query: [scope: "admin"])
head!(client, "/users")
head!(client, "/users", query: [scope: "admin"])
head!(client, "/users", body: %{name: "Jon"})
ledger_entry_regex()
Each ledger entry has a unique ID. The ID is derived by hashing important contents of the entry, along with a namespace identifier. The ledger entry type determines the namespace identifier to use and which contents to include in the hash. This ensures every ID is unique. The hash function is SHA-512Half.
Generally, a ledger entry's ID is returned as the index field in JSON, at the same level as the object's contents. In transaction metadata, the ledger object's ID in JSON is LedgerIndex.
Offer directories have special IDs, where part of the hash is replaced with the exchange rate of Offers in that directory.
Official documentation: https://xrpl.org/docs/references/protocol/ledger-data/common-fields/
ledger_hash_regex()
ledger_index_regex()
A ledger index is a 32-bit unsigned integer used to identify a ledger. The ledger index is sometimes known as the ledger's sequence number. (This is different from an account sequence.) The very first ledger was ledger index 1, and each new ledger has a ledger index that is 1 higher than the ledger index of the ledger immediately before it.
The ledger index indicates the order of the ledgers; the [Hash][] value identifies the exact contents of the ledger. Two ledgers with the same hash are always the same. For validated ledgers, hash values and ledger indexes are equally valid and correlate 1:1. However, this is not true for in-progress ledgers:
Two different rippled servers may have different contents for a current ledger with the same ledger index, due to latency in propagating transactions throughout the network. There may be multiple closed ledger versions competing to be validated by consensus. These ledger versions have the same ledger index but different contents (and different hashes). Only one of these closed ledgers can become validated. The current open ledger's hash is not calculated. This is because a current ledger's contents change over time, which would cause its hash to change, even though its ledger index stays the same. The hash of a ledger is only calculated when the ledger is closed. Specifying Ledgers Many API methods require you to specify an instance of the ledger, with the data retrieved being considered up-to-date as of that particular version of the shared ledger. The commands that accept a ledger version all work the same way. There are three ways you can specify which ledger you want to use:
Specify a ledger by its Ledger Index in the ledger_index parameter. Each closed ledger has a ledger index that is 1 higher than the previous ledger. (The very first ledger had ledger index 1.)
"ledger_index": 61546724 Specify a ledger by its Hash value in the ledger_hash parameter.
"ledger_hash": "8BB204CE37CFA7A021A16B5F6143400831C4D1779E6FE538D9AC561ABBF4A929" Specify a ledger by one of the following shortcuts, in the ledger_index parameter:
validated for the most recent ledger that has been validated by consensus
"ledger_index": "validated" closed for the most recent ledger that has been closed for modifications and proposed for validation
current for the server's current working version of the ledger.
There is also a deprecated ledger parameter which accepts any of the above three formats. Do not use this parameter; it may be removed without further notice.
If you do not specify a ledger, the server decides which ledger to use to serve the request. By default, the server chooses the current (in-progress) ledger. In Reporting Mode, the server uses the most recent validated ledger instead. Do not provide more than one field specifying ledgers.
Note: Do not rely on the default behavior for specifying a ledger; it is subject to change. Always specify a ledger version in the request if you can.
Reporting Mode does not record ledger data until it has been validated. If you make a request to a Reporting Mode server for the current or closed ledger, the server forwards the request to a P2P Mode server. If you request a ledger index or hash that is not validated, a Reporting Mode server responds with a lgrNotFound error. Official documentation: https://xrpl.org/docs/references/protocol/data-types/basic-data-types/#ledger-index
options(client, url, opts)
@spec options(Tesla.Env.client(), Tesla.Env.url(), [option()]) :: Tesla.Env.result()
Perform a OPTIONS request.
See request/1
or request/2
for options definition.
options("/users")
options("/users", query: [scope: "admin"])
options(client, "/users")
options(client, "/users", query: [scope: "admin"])
options(client, "/users", body: %{name: "Jon"})
options!(client, url, opts)
@spec options!(Tesla.Env.client(), Tesla.Env.url(), [option()]) :: Tesla.Env.t() | no_return()
Perform a OPTIONS request.
See request!/1
or request!/2
for options definition.
options!("/users")
options!("/users", query: [scope: "admin"])
options!(client, "/users")
options!(client, "/users", query: [scope: "admin"])
options!(client, "/users", body: %{name: "Jon"})
patch(client, url, body, opts)
@spec patch(Tesla.Env.client(), Tesla.Env.url(), Tesla.Env.body(), [option()]) :: Tesla.Env.result()
Perform a PATCH request.
See request/1
or request/2
for options definition.
patch("/users", %{name: "Jon"})
patch("/users", %{name: "Jon"}, query: [scope: "admin"])
patch(client, "/users", %{name: "Jon"})
patch(client, "/users", %{name: "Jon"}, query: [scope: "admin"])
patch!(client, url, body, opts)
@spec patch!(Tesla.Env.client(), Tesla.Env.url(), Tesla.Env.body(), [option()]) :: Tesla.Env.t() | no_return()
Perform a PATCH request.
See request!/1
or request!/2
for options definition.
patch!("/users", %{name: "Jon"})
patch!("/users", %{name: "Jon"}, query: [scope: "admin"])
patch!(client, "/users", %{name: "Jon"})
patch!(client, "/users", %{name: "Jon"}, query: [scope: "admin"])
post(client, url, body, opts)
@spec post(Tesla.Env.client(), Tesla.Env.url(), Tesla.Env.body(), [option()]) :: Tesla.Env.result()
Perform a POST request.
See request/1
or request/2
for options definition.
post("/users", %{name: "Jon"})
post("/users", %{name: "Jon"}, query: [scope: "admin"])
post(client, "/users", %{name: "Jon"})
post(client, "/users", %{name: "Jon"}, query: [scope: "admin"])
post!(client, url, body, opts)
@spec post!(Tesla.Env.client(), Tesla.Env.url(), Tesla.Env.body(), [option()]) :: Tesla.Env.t() | no_return()
Perform a POST request.
See request!/1
or request!/2
for options definition.
post!("/users", %{name: "Jon"})
post!("/users", %{name: "Jon"}, query: [scope: "admin"])
post!(client, "/users", %{name: "Jon"})
post!(client, "/users", %{name: "Jon"}, query: [scope: "admin"])
public_key_regex()
put(client, url, body, opts)
@spec put(Tesla.Env.client(), Tesla.Env.url(), Tesla.Env.body(), [option()]) :: Tesla.Env.result()
Perform a PUT request.
See request/1
or request/2
for options definition.
put("/users", %{name: "Jon"})
put("/users", %{name: "Jon"}, query: [scope: "admin"])
put(client, "/users", %{name: "Jon"})
put(client, "/users", %{name: "Jon"}, query: [scope: "admin"])
put!(client, url, body, opts)
@spec put!(Tesla.Env.client(), Tesla.Env.url(), Tesla.Env.body(), [option()]) :: Tesla.Env.t() | no_return()
Perform a PUT request.
See request!/1
or request!/2
for options definition.
put!("/users", %{name: "Jon"})
put!("/users", %{name: "Jon"}, query: [scope: "admin"])
put!(client, "/users", %{name: "Jon"})
put!(client, "/users", %{name: "Jon"}, query: [scope: "admin"])
request(client \\ %Tesla.Client{}, options)
@spec request(Tesla.Env.client(), [option()]) :: Tesla.Env.result()
Perform a request.
Options
:method
- the request method, one of [:head
,:get
,:delete
,:trace
,:options
,:post
,:put
,:patch
]:url
- either full url e.g. "http://example.com/some/path" or just "/some/path" if usingTesla.Middleware.BaseUrl
:query
- a keyword list of query params, e.g.[page: 1, per_page: 100]
:headers
- a keyworld list of headers, e.g.[{"content-type", "text/plain"}]
:body
- depends on used middleware:- by default it can be a binary
- if using e.g. JSON encoding middleware it can be a nested map
- if adapter supports it it can be a Stream with any of the above
:opts
- custom, per-request middleware or adapter options
Examples
ExampleApi.request(method: :get, url: "/users/path")
# use shortcut methods
ExampleApi.get("/users/1")
ExampleApi.post(client, "/users", %{name: "Jon"})
request!(client \\ %Tesla.Client{}, options)
@spec request!(Tesla.Env.client(), [option()]) :: Tesla.Env.t() | no_return()
Perform request and raise in case of error.
This is similar to request/2
behaviour from Tesla 0.x
See request/2
for list of available options.
trace(client, url, opts)
@spec trace(Tesla.Env.client(), Tesla.Env.url(), [option()]) :: Tesla.Env.result()
Perform a TRACE request.
See request/1
or request/2
for options definition.
trace("/users")
trace("/users", query: [scope: "admin"])
trace(client, "/users")
trace(client, "/users", query: [scope: "admin"])
trace(client, "/users", body: %{name: "Jon"})
trace!(client, url, opts)
@spec trace!(Tesla.Env.client(), Tesla.Env.url(), [option()]) :: Tesla.Env.t() | no_return()
Perform a TRACE request.
See request!/1
or request!/2
for options definition.
trace!("/users")
trace!("/users", query: [scope: "admin"])
trace!(client, "/users")
trace!(client, "/users", query: [scope: "admin"])
trace!(client, "/users", body: %{name: "Jon"})