Use this reference to configure endpoints, shape requests, match batch responses, and handle errors. GraphOps RPC exposes Ethereum-compatible JSON-RPC over HTTPS and WebSocket, plus Bitcoin JSON-RPC over HTTPS. For individual methods, see Supported methods.
Endpoint patterns
Reference
https://rpc.graphops.xyz/v1/evm/<CHAIN_ID>
wss://rpc.graphops.xyz/v1/evm/<CHAIN_ID>
Endpoint preview
Replace placeholders with your identifier and API key before making requests.
Use the concrete URL for your target chain in application configuration or client setup.
See Supported networks for current query endpoints and archive coverage.
Bitcoin endpoints
Bitcoin RPC uses HTTPS and a network name instead of an EVM chain ID. The endpoint route is:
Reference
https://rpc.graphops.xyz/v1/bitcoin/<NETWORK>
For example, this request reads Bitcoin mainnet chain information. EVM client libraries do not support Bitcoin JSON-RPC, so the programs use an HTTP client:
Prerequisites
Set GRAPHOPS_API_KEY to your GraphOps API key.
CLI · curl
curl --fail-with-body --silent --show-error "https://rpc.graphops.xyz/v1/bitcoin/mainnet" \
-H "Authorization: Bearer ${GRAPHOPS_API_KEY}" \
-H "Content-Type: application/json" \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "getblockchaininfo",
"params": []
}'
Clients that cannot attach headers can use the route-token form instead:
Reference
https://rpc.graphops.xyz/v1/bitcoin/mainnet/<GRAPHOPS_API_KEY>
Authentication
Authenticate with an organization-scoped API key. RPC supports header authentication and route-token authentication. See Authentication for key creation, rotation, WebSocket connections, and secret handling.
Request envelope
Every EVM and Bitcoin JSON-RPC call uses the standard request envelope. Method names and parameter formats are network-specific; the examples in this section use EVM methods.
| Field | Type | Required | Notes |
|---|---|---|---|
jsonrpc | string | Yes | Must be "2.0". |
id | string, number, or null | Required for request/response calls | Use a stable value so clients can match responses, especially in batches. |
method | string | Yes | Standard Ethereum-compatible method name, such as eth_blockNumber. |
params | array or object | Method-specific | Ethereum JSON-RPC methods usually use positional arrays. |
JSON
{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_blockNumber",
"params": []
}
Output
{ "jsonrpc": "2.0",JSON-RPC version "id": 1,Matches the id you sent "result": "0x191161d"Latest block in decimal: 26,285,597}HTTPS requests
HTTPS requests use POST with Content-Type: application/json. The examples below use Ethereum
mainnet.
Prerequisites
Set GRAPHOPS_API_KEY to your GraphOps API key.
CLI · curl
curl --fail-with-body --silent --show-error "https://rpc.graphops.xyz/v1/evm/1" \
-H "Authorization: Bearer ${GRAPHOPS_API_KEY}" \
-H "Content-Type: application/json" \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_blockNumber",
"params": []
}'
Output
{ "jsonrpc": "2.0",JSON-RPC version "id": 1,Matches the id you sent "result": "0x191161d"Latest block in decimal: 26,285,597}Batch requests
Batch requests are supported. Use them when several independent calls can share one HTTP round trip. Do not use a batch when later calls depend on earlier results.
JSON
[
{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_blockNumber",
"params": []
},
{
"jsonrpc": "2.0",
"id": 2,
"method": "eth_chainId",
"params": []
},
{
"jsonrpc": "2.0",
"id": 3,
"method": "eth_getBalance",
"params": ["0xnot-an-address", "latest"]
}
]
Output
[ { "jsonrpc": "2.0", "id": 1, "result": "0x191f63a"eth_blockNumber in decimal: 26,342,970 }, { "jsonrpc": "2.0", "id": 2, "result": "0x1"Ethereum mainnet chain ID: 1 }, { "jsonrpc": "2.0", "id": 3, "error": { "code": -32602,Only this call failed: invalid parameters "message": "Invalid params" } }]In the output, the third call fails because its address is invalid; the other two succeed.
Match responses by id; do not rely on response ordering. Retry only the failed items that are
retryable, as a smaller batch or as single requests.
WebSocket connections
Use WebSocket endpoints for subscriptions and long-lived event streams. Route-token authentication works with WebSocket clients that cannot attach custom headers during the handshake.
Prerequisites
Install Node.js.
Install tsx and ws.
npm install tsx wsSet GRAPHOPS_API_KEY to your GraphOps API key.
TypeScript · ws
import WebSocket from "ws";
// Route-token URL: the API key is the final path segment.
const socket = new WebSocket(
`wss://rpc.graphops.xyz/v1/evm/1/${process.env.GRAPHOPS_API_KEY}`,
);
socket.once("error", (error) => { throw error; });
socket.once("open", () => {
console.log(JSON.stringify({ connected: true }));
socket.close();
});
See Authentication for header authentication, route-token authentication, and security guidance.
WebSocket subscriptions
GraphOps supports standard Ethereum subscription flows over WebSocket:
| Subscription | Use it for |
|---|---|
newHeads | Receive new block headers. |
logs | Receive logs matching an address and topic filter. |
newPendingTransactions | Receive pending transaction hashes when available for the network. |
syncing | Receive node sync status updates. |
Persist the last processed block or log cursor in your application. If a WebSocket disconnects, use WebSocket subscriptions for recovery patterns.
Error responses
JSON-RPC errors use the standard error object in place of result:
JSON
{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_getBalance",
"params": [
"invalid-address",
"latest"
]
}
Output
{ "jsonrpc": "2.0", "id": 1,The call that failed "error": {Present instead of result "code": -32602,Invalid params; see the table below "message": "odd number of digits"Points at the first parameter }}Common error classes. GraphOps error responses carry a code; look it up in the
gateway errors or API key errors reference.
| Code or status | Meaning | Typical response |
|---|---|---|
400 | Malformed HTTP request, invalid JSON, or a body that is not a JSON-RPC request object or batch. GraphOps rejects these before they reach a node, so they return HTTP 400 rather than JSON-RPC -32700 or -32600. Over WebSocket, an invalid message closes the connection with code 1008. | Fix request encoding and the JSON-RPC envelope. |
401 | Missing or invalid API key. | Check header or route-token authentication. |
403 | The key is valid, but its limits do not include the network you called, the organization has no credits left, the key does not cover the route, or GraphOps support paused the organization or disabled the key. | Check the response code: allow the network in the key's limits, top up credits, check the endpoint, or contact support. See Troubleshooting. |
413 | The request body is too large. | Send a smaller request or split the batch. |
415 | The request uses an unsupported Content-Encoding. | Send the body uncompressed or with gzip, deflate, br or zstd. |
429 | Organization exceeded rate or concurrency limits. | Back off and reduce concurrency. |
502 | The node returned an invalid or oversized response, or the request to it failed. | Retry; for large results, request a smaller block range or fewer items. |
503 | The service is temporarily unavailable. | Retry with backoff. |
504 | The node did not respond in time. | Retry, or reduce the work per request. |
-32600 | Invalid JSON-RPC request envelope reported by the node. | Include jsonrpc, method, and valid id when needed. |
-32601 | Method not found. | Check method spelling, transport, and network support. |
-32602 | Invalid params. | Check parameter order, hex encoding, and block tag. |
-32603 | Internal JSON-RPC error. | Retry if transient; contact support if persistent. |
-32000 to -32099 | Server or EVM execution error. | Inspect the message and method-specific context. |
Next steps
Last updated