Network
The RPC API enables you to query status information for nodes and validators.
Node Status
Returns general status of a given node (sync status, nearcore node version, protocol version, etc), and the current set of validators.
method:
status
params:
[]
Example:
{
"jsonrpc": "2.0",
"id": "dontcare",
"method": "status",
"params": []
}
What could go wrong?
When API request fails, RPC server returns a structured error response with a limited number of well-defined error variants, so client code can exhaustively handle all the possible error cases. Our JSON-RPC errors follow verror convention for structuring the error response:
{
"error": {
"name": <ERROR_TYPE>,
"cause": {
"info": {..},
"name": <ERROR_CAUSE>
},
"code": -32000,
"data": String,
"message": "Server error",
},
"id": "dontcare",
"jsonrpc": "2.0"
}
Heads up
The fields
code
,data
, andmessage
in the structure above are considered legacy ones and might be deprecated in the future. Please, don't rely on them.
Here is the exhaustive list of the error variants that can be returned by status
method:
ERROR_TYPE
error.name
ERROR_CAUSE
error.cause.name
Reason
Solution
INTERNAL_ERROR
INTERNAL_ERROR
Something went wrong with the node itself or overloaded
Try again later
Send a request to a different node
Check
error.cause.info
for more details
Network Info
Returns the current state of node network connections (active peers, transmitted data, etc.)
method:
network_info
params: none
Example:
{
"jsonrpc": "2.0",
"id": "dontcare",
"method": "network_info",
"params": []
}
What could go wrong?
When API request fails, RPC server returns a structured error response with a limited number of well-defined error variants, so client code can exhaustively handle all the possible error cases. Our JSON-RPC errors follow verror convention for structuring the error response:
{
"error": {
"name": <ERROR_TYPE>,
"cause": {
"info": {..},
"name": <ERROR_CAUSE>
},
"code": -32000,
"data": String,
"message": "Server error",
},
"id": "dontcare",
"jsonrpc": "2.0"
}
Heads up
The fields
code
,data
, andmessage
in the structure above are considered legacy ones and might be deprecated in the future. Please, don't rely on them.
Here is the exhaustive list of the error variants that can be returned by network_info
method:
ERROR_TYPE
error.name
ERROR_CAUSE
error.cause.name
Reason
Solution
INTERNAL_ERROR
INTERNAL_ERROR
Something went wrong with the node itself or overloaded
Try again later
Send a request to a different node
Check
error.cause.info
for more details
Validation Status
Queries active validators on the network returning details and the state of validation on the blockchain.
method:
validators
params:
["block hash"]
,[block number]
,{"epoch_id": "epoch id"}
,{"block_id": block number}
,{"block_id": "block hash"}
, or[null]
for the latest block
Note: If you want the latest block hash
, block number
and epoch id
, you will need to query from the last block in an epoch. You can also query validators endpoint for past epochs if you input block hash
, block number
or epoch id
of the past epoch that you want.
Example:
input: [block number]
{
"jsonrpc": "2.0",
"id": "dontcare",
"method": "validators",
"params": [17791098]
}
input: ["block hash"]
{
"jsonrpc": "2.0",
"id": "dontcare",
"method": "validators",
"params": ["FiG2nMjjue3YdgYAyM3ZqWXSaG6RJj5Gk7hvY8vrEoGw"]
}
input: {"block_id": "block hash"}
{
"jsonrpc": "2.0",
"id": "dontcare",
"method": "validators",
"params": {
"block_id": "FiG2nMjjue3YdgYAyM3ZqWXSaG6RJj5Gk7hvY8vrEoGw"
}
}
input: {"block_id": block number}
{
"jsonrpc": "2.0",
"id": "dontcare",
"method": "validators",
"params": {
"block_id": 17791098
}
}
input: {"epoch_id": "epoch id"}
{
"jsonrpc": "2.0",
"id": "dontcare",
"method": "validators",
"params": {
"epoch_id": "8hJSZNNyimPvsCA1v3dMr3Hg5ucYeLUbTvEfhr6jaWJy"
}
}
input: [null]
{
"jsonrpc": "2.0",
"id": "dontcare",
"method": "validators",
"params": [null]
}
What could go wrong?
When API request fails, RPC server returns a structured error response with a limited number of well-defined error variants, so client code can exhaustively handle all the possible error cases. Our JSON-RPC errors follow verror convention for structuring the error response:
{
"error": {
"name": <ERROR_TYPE>,
"cause": {
"info": {..},
"name": <ERROR_CAUSE>
},
"code": -32000,
"data": String,
"message": "Server error",
},
"id": "dontcare",
"jsonrpc": "2.0"
}
Heads up
The fields
code
,data
, andmessage
in the structure above are considered legacy ones and might be deprecated in the future. Please, don't rely on them.
Here is the exhaustive list of the error variants that can be returned by validators
method:
ERROR_TYPE
error.name
ERROR_CAUSE
error.cause.name
Reason
Solution
HANDLER_ERROR
UNKNOWN_EPOCH
An epoch for the provided block can't be found in a database
Check that the requested block is legit
If the block had been produced more than 5 epochs ago, try to send your request to an archival node
Check that the requested block is the last block of some epoch
REQUEST_VALIDATION_ERROR
PARSE_ERROR
Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
Check the arguments passed and pass the correct ones
Check
error.cause.info
for more details
INTERNAL_ERROR
INTERNAL_ERROR
Something went wrong with the node itself or overloaded
Try again later
Send a request to a different node
Check
error.cause.info
for more details
Last updated