Ethereum JSON-RPC transport (POST /rpc/eth)

POST /rpc/eth is the single endpoint through which all Ethereum execution-layer JSON-RPC methods (eth_*, trace_*, debug_*, txpool_*) are served. You send a standard JSON-RPC 2.0 request object and receive a standard JSON-RPC 2.0 response. This page documents the transport — how a request is classified, routed, and authorized. The individual methods are documented separately under the Ethereum JSON-RPC reference (generated from eth.openrpc.json); they are not re-listed here.

Each incoming request is inspected and dispatched by method:

• Read & trace methods (eth_*, trace_*, debug_*, txpool_status, txpool_content, txpool_inspect) are routed to the EL node pool: a primary mesh host is picked, and on a routing error the request transparently falls through a fallback chain — no error surfaces to you as long as one upstream can serve the call.
• Write methods (eth_sendRawTransaction, eth_sendTransaction, eth_signTransaction) are forwarded to the dedicated transaction-send channel rather than the read pool.
• Privileged namespaces (admin_*, personal_*, engine_*) are never forwarded. They are rejected at the edge with a JSON-RPC error (-32601, "<namespace> namespace disabled"). Classification is case-insensitive, so Admin_peers is rejected exactly like admin_peers.
• Batch requests (a JSON array of request objects) are accepted but routed straight to the fallback chain — the mesh pool serves single calls only.

Authentication, tier, and scope are enforced by the transport before any routing decision: present a key holding the eth:rpc scope, and the per-method rate limit is applied according to the method's category.

The request body is a single JSON-RPC 2.0 object (or, for batch, an array of them). The method and params are those of the underlying Ethereum EL method.

The response is the upstream method's JSON-RPC result, passed through unchanged. The Content-Type is always application/json.

JSON-RPC errors are envelope-level: they return HTTP 200 with an error object in the body. Transport-level failures (auth, body parsing, no upstream) use HTTP status codes.

The underlying method may also return its own JSON-RPC error codes (e.g. -32602 invalid params). See Errors for the full envelope and the typed fields on each code.

JavaScript (fetch)

const res = await fetch("https://api.triport.io/rpc/eth", {
  method: "POST",
  headers: {
    "x-token": process.env.TRIPORT_API_KEY,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    jsonrpc: "2.0",
    id: 1,
    method: "eth_blockNumber",
    params: [],
  }),
});


const { result } = await res.json();
console.log("latest block:", parseInt(result, 16));

TypeScript SDK (@triport/sdk)

import { TriportClient } from "@triport/sdk";


const client = new TriportClient({ apiKey: process.env.TRIPORT_API_KEY! });


// The SDK targets POST /rpc/eth under the hood.
const blockHex: string = await client.ethereum.rpc("eth_blockNumber");
console.log("latest block:", parseInt(blockHex, 16));

Python (triport-sdk)

import os
from triport import TriportClient


client = TriportClient(api_key=os.environ["TRIPORT_API_KEY"])


block_hex = client.ethereum.rpc("eth_blockNumber")
print("latest block:", int(block_hex, 16))

• This is the transport, not the methods. For parameters, result shapes, and per-method tiers, see the Ethereum JSON-RPC reference.
• Single calls route through the node pool; batches do not. A JSON-RPC batch (array body) is served by the fallback chain rather than the mesh pool. Split large batches into single calls when you want pool routing.
• Privileged namespaces are off by design. admin_*, personal_*, and engine_* always return -32601 and never reach an upstream node.
• Writes use a separate path. eth_sendRawTransaction and the other write methods are forwarded to the transaction-send channel automatically — you call them through this same endpoint.
• Related: Authentication · Rate limits · Errors