Endpoints

Endpoints follow a predictable pattern. The network comes first, then the layer:

• Execution Layer (JSON-RPC): {network}.rpc.ethnodeops.xyz
• Consensus Layer (Beacon REST API): {network}.ebeacon.ethnodeops.xyz

These are load-balanced across all clients we run for that network. Most requests should work without specifying a client. To pin a request to a specific client, see Supported clients.

Execution Layer (JSON-RPC)

Standard Ethereum JSON-RPC over HTTPS. Send requests as POST.

Consensus Layer (Beacon REST API)

The standard Beacon Node REST API. Most endpoints are GET requests under /eth/v1/....

Quick checks

Latest execution block on Mainnet:

curl https://mainnet.rpc.ethnodeops.xyz/YOUR_API_KEY \
  -X POST -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

Beacon node version on Hoodi:

curl https://hoodi.ebeacon.ethnodeops.xyz/YOUR_API_KEY/eth/v1/node/version

Health checks

Every endpoint exposes a /healthz path you can poll to confirm the network and layer are serving traffic — useful for uptime monitors, readiness probes, and load balancers. Authenticate health checks with the X-API-Key header — the URL-path key isn't supported on /healthz.

# Execution Layer
curl https://mainnet.rpc.ethnodeops.xyz/healthz \
  -H "X-API-Key: YOUR_API_KEY"

# Consensus Layer
curl https://mainnet.ebeacon.ethnodeops.xyz/healthz \
  -H "X-API-Key: YOUR_API_KEY"

# A specific Consensus Layer client
curl https://lighthouse.mainnet.ebeacon.ethnodeops.xyz/healthz \
  -H "X-API-Key: YOUR_API_KEY"

A healthy endpoint responds with a 200 status. Swap mainnet for any supported network, and rpc or ebeacon for the layer you want to check. You can also prefix a client name to health-check one client directly — e.g. lighthouse.mainnet.ebeacon. See Supported clients for the routing scheme.

Need to target one specific client implementation? Head to Supported clients.