Starting with v6.0 BEAM wallet supports API versioning using the --api_version
option. Please choose the corresponding API version in the list below to get the description of the available methods.
The sections below apply to the API versions starting with 6.0 if the other is not explicitly stated.
General
Wallet API has the same structure as Node Stratum API protocol (JSON RPC 2.0 over TCP connection) and should have an online connection to the node. However, it can work over HTTP using the --use_http=1
option. Send POST requests to http://x.x.x.x:port/api/wallet
in this case.
Running Wallet API
Place wallet-api
binary located in the wallet
folder near your wallet.db
and run it. You can specify options in CLI or using wallet-api.cfg
file. Minimal options required are your wallet.db
password (--pass
) and node (-n=
) to connect to. Please notice that node.db
by default is expected to be located in the current working directory ($PWD
). You can change this using the --wallet_path=
option.
Wallet API general options
-h [ --help ] list of all options
-p [ --port ] arg (=10000) port to start server on
-n [ --node_addr ] arg address of node
--wallet_path arg (=wallet.db) path to the wallet file
--pass arg password for the wallet
--use_http arg (=0) use JSON RPC over HTTP
--ip_whitelist arg IP whitelist
--log_cleanup_days arg (=5) old logfiles cleanup period(days)
--node_poll_period arg (=0) Node poll period in milliseconds. Set
to 0 to keep a connection. Anyway poll
period would be no less than the
expected rate of blocks if it is less
then it will be rounded up to block
rate value.
--enable_assets enable confidential assets transactions
--enable_lelantus enable Lelantus MW transactions
--api_version specify API version. Available since v6.0. Acceptable values: current, 6.0, 6.1 &c.
User authorization options:
--use_acl arg (=0) use Access Control List (ACL)
--acl_path arg (=wallet_api.acl) path to ACL file
TLS protocol options:
--use_tls arg (=0) use TLS protocol
--tls_cert arg (=wallet_api.crt) path to TLS certificate
--tls_key arg (=wallet_api.key) path to TLS private key
--tls_request_cert (=false) request client's certificate for verification for client authentication
--tls_reject_unauthorized (=true) server will reject any connection which is not authorized with the list of supplied CAs
wallet-api.cfg file
The wallet-api.cfg
file is another way to supply options for the API server. All the options listed above are supported. The wallet-api.cfg
file is expected to be located in the current working directory ($PWD
). Here is an example of the wallet-api.cfg
file:
# password for the wallet
pass=1
# address of node
node_addr=127.0.0.1:8888
# port to start server on
port=10000
# path to wallet file
wallet_path=/home/user/wallet.db
# use JSON RPC over HTTP
use_http=1
Running API Server in TCP mode
By default API launches in TCP mode. For example:
./wallet-api --node_addr=172.104.249.212:8101 --pass=123
Accessing API Server via TCP
Here is an example NodeJS code to get all UTXOs from the Wallet API server that is running in TCP mode
var net = require('net');
var client = new net.Socket();
client.connect(10000, '127.0.0.1', function() {
console.log('Connected');
client.write(JSON.stringify(
{
jsonrpc: '2.0',
id: 123,
method: 'get_utxo',
params: {}
}) + '\n');
});
var acc = '';
client.on('data', function(data) {
acc += data;
// searching for \n symbol to find end of response
if(data.indexOf('\n') != -1)
{
var res = JSON.parse(acc);
console.log('Received:', res);
client.destroy(); // kill client after server's response
}
});
client.on('close', function() {
console.log('Connection closed');
});
Running API Server in HTTP mode
Run via cli with '--use_http=1':
./wallet-api --node_addr=172.104.249.212:8101 --pass=123 --use_http=1
Or add 'use_http=1' to the wallet-api.cfg to enable HTTP mode.
Accessing API Server via HTTP
You can perform POST requests using CURL. Here is an example to get the current wallet status.
curl -d '{"jsonrpc":"2.0","id":1,"method":"wallet_status"}'
-H "Content-Type: application/json"
-X POST http://x.x.x.x:port/api/wallet
TLS encryption
Add --use_tls=1
to enable TLS encryption. You have supply the valid 3rd-party certificate or create a self signed certificate. Pass them to the API server using --tls_cert
and --tls_key
options.
For testing you can download the sample certificate and key files from here or clicking the links below:
Certificate File
Certificate Private Key File
IP whitelisting
Add --ip_whitelist=192.168.0.1,192.168.0.2
parameter to restrict access to the API server to certain IP addresses. Connections from other IP address would be rejected.
Users authorization
API methods can have access rights control if you enable Access Control List (ACL) using --use_acl=1
option. Below is the list of all API methods with the access rights required to call the respective method:
create_address - write access
validate_address - read access
addr_list - read access
delete_address - write access
edit_address - write access
tx_send - write access
tx_status - read access
tx_split - write access
tx_asset_issue - write access
tx_asset_consume - write access
tx_asset_info - write access
tx_cancel - write access
get_utxo - read access
tx_list - read access
wallet_status - read access
get_asset_info - read access
generate_tx_id - read access
export_payment_proof - read access
verify_payment_proof - read access
calc_change - read access
invoke_contract - write access
process_invoke_data - write access
block_details - read access
ACL file should look like a list with the access keys and read/write
rights:
472e17b0419055ffee3b3813b98ae671579b0ac0dcd6f1a23b11a75ab148cc67 : write
bd39333a66a8b7cb3804b5978d42312c841dbfa03a1c31fc2f0627eeed6e43f2 : read
f287176bdd517e9c277778e4c012bf6a3e687dd614fc552a1ed22a3fee7d94f2 : read
Don't forget to send user key
in every JSONRPC request to the API if access control is enabled:
{
"jsonrpc": "2.0",
"id": 1,
"method": "wallet_status",
"key": "bd39333a66a8b7cb3804b5978d42312c841dbfa03a1c31fc2f0627eeed6e43f2"
}
API Errors Handling
Errors are returned as:
error: {
code: -32003,
data: "It's not your own address.",
message: 'Invalid address.'
}
where
code
is a unique identifier of the errormessage
textual description of the errordata
is the contextual data for the error, usually a more detailed description for general error codes
To get the list of the possible error codes check the respective API version.
Assets Support
v6.0+ API implements confidential assets support. To ensure backward compatibility by default API does not return asset entities (coins, balances, txs &c). Asset operations (send, receive, issue, consume &c.) are disabled as well and if requested for an asset would fail. Also, all incoming transactions that involve assets would be rejected by the Wallet API as well. If you do not enable assets support your old code should be able to use the new API without any changes.
To enable assets start your API server with the --enable_assets
option or set this flag to true in the config file.
Methods that can return asset entities (for example wallet_status
or get_utxo
) might have different return formats if assets are enabled. Please check the respective methods' documentation for details.
In most method responses an additional asset_id
field is returned by default even if assets support is not enabled. It is always 0 for BEAM and can be safely ignored.
IPFS Support
String with v6.3 BEAM comes with built-in IPFS support. Please refer to the following pages for more details