Skip to main content

Why Migrate?

All new features, endpoints, and improvements are built exclusively for V2. We recommend migrating to V2 for the best experience.
  • Richer data: V2 endpoints return more detailed, structured responses with fine-grained reward breakdowns
  • Flexible selectors: Query by validator index, public key, deposit address, withdrawal address, entity, or dashboard
  • Use cases and guides: 14+ step-by-step guides with code examples for common workflows
  • BeaconScore and entities: Exclusive V2 features for performance benchmarking and entity comparison
  • Active development: All new features ship on V2 only

Need Help?

Use Cases

Task-specific guides with code examples for common operations.

Error Handling

V2 error patterns, status codes, and troubleshooting.

AI Integration

Connect your AI assistant to the beaconcha.in docs via MCP or llms.txt.

Discord

Ask questions and get help from the community.

Key Differences

AspectV1 APIV2 API
HTTP methodMostly GETAll POST
AuthenticationQuery param (?apikey=) or header (apikey: ...)Bearer token (Authorization: Bearer <key>)
PaginationOffset-based (offset and limit)Cursor-based (cursor and page_size)
Validator selectionPath parameter (single index or pubkey)JSON body selector (batch indices, pubkeys, deposit address, withdrawal address, entity, dashboard, or dashboard group ID)
Response envelope{ "status": "OK", "data": ... }{ "data": ..., "paging": ... }
Chain selectionImplicit (server URL)Explicit "chain" field in request body ("mainnet" or "hoodi")

Endpoint Mapping

Network State

V1V2Notes
GET /api/v1/latestStatePOST /api/v2/ethereum/statePending API: the beaconcha.in team is working on this API.

Validators

V1V2Notes
GET /api/v1/validator/{indexOrPubkey}POST /api/v2/ethereum/validatorsV2 supports batch lookups in a single request
POST /api/v1/validatorPOST /api/v2/ethereum/validatorsV2 handles batching natively via validator_identifiers array
GET .../validator/eth1/{eth1address}POST /api/v2/ethereum/validatorsUse the deposit_address selector in the request body.
GET .../validator/withdrawalCredentials/{...}POST /api/v2/ethereum/validatorsUse the withdrawal selector in the request body.
GET .../balancehistoryPOST .../validators/balances
GET .../performancePOST .../validators/performance-aggregateV1 returns rolling window totals (1d/7d/31d/365d). V2 performance-aggregate is the closest match. For per-epoch granularity, use performance-list
GET .../attestationsPOST .../validators/attestation-slots
GET .../proposalsPOST .../validators/proposal-slots
GET .../attestationefficiencyPOST .../validators/performance-aggregateBeaconScore in V2 replaces the V1 attestation efficiency metric
GET .../depositsPOST .../validators/deposit-slotsPending API: the beaconcha.in team is working on this API.
GET .../withdrawalsPOST .../validators/withdrawal-slotsPending API: the beaconcha.in team is working on this API.

Rewards

V1V2Notes
GET .../incomedetailhistoryPOST .../validators/rewards-list
GET .../execution/performancePOST .../validators/rewards-aggregateV1 is execution-layer only. V2 includes both consensus and execution layer rewards
GET .../execution/block/{blockNumber}POST .../block/rewardsUse this endpoint for execution-layer block reward details.

Queues and Sync Committees

V1V2Notes
GET /api/v1/validators/queuePOST /api/v2/ethereum/queuesNetwork-wide queue data. For per-validator queue position, see also validators/queues Pending. The beaconcha.in team is working on this endpoint.
GET /api/v1/sync_committee/{period}POST /api/v2/ethereum/sync-committee

Slots

V1V2Notes
GET /api/v1/slot/{slotOrHash}POST /api/v2/ethereum/slot
GET .../slot/{slot}/attestationsPOST .../slot/attestation-dutiesPending API: the beaconcha.in team is working on this API.
GET .../slot/{slot}/depositsPOST .../slot/depositsPending API: the beaconcha.in team is working on this API.
GET .../slot/{slot}/withdrawalsPOST .../slot/withdrawalsPending API: the beaconcha.in team is working on this API.

V1-Only Endpoints (No V2 Equivalent Yet)

The following V1 endpoints do not have V2 equivalents at this time. They remain accessible via the V1 API.
CategoryV1Notes
ValidatorsGET .../validator/{indexOrPubkey}/blsChangeBLS-to-execution credential changes
ValidatorsGET .../validator/stats/{index}Daily validator statistics
ValidatorsGET .../validator/leaderboardPerformance leaderboard
ValidatorsGET .../validators/proposalLuckProposal luck metrics
ValidatorsGET .../eth1deposit/{txhash}Deposits by execution transaction hash
EpochsGET /api/v1/epoch/{epoch}Epoch overview
EpochsGET /api/v1/epoch/{epoch}/slotsAll slots in an epoch
SlotsGET .../slot/{slot}/attesterslashingsAttester slashings
SlotsGET .../slot/{slot}/proposerslashingsProposer slashings
SlotsGET .../slot/{slot}/voluntaryexitsVoluntary exits
Execution LayerGET .../execution/address/{address}Address balances
Execution LayerGET .../execution/address/{address}/erc20tokensERC-20 token balances
Execution LayerGET .../execution/{addressIndexOrPubkey}/producedBlocks produced by fee recipient
Execution LayerGET .../execution/gasnowGas price recommendations
OtherGET /api/v1/rocketpool/statsRocket Pool network statistics
OtherGET /api/v1/rocketpool/validator/{indexOrPubkey}Rocket Pool validator metadata
OtherGET /api/v1/ethstore/{day}ETH.Store daily aggregates
OtherGET /api/v1/ens/lookup/{domain}ENS resolution
OtherGET /api/v1/chart/{chart}Chart data
OtherGET /api/v1/graffitiwallGraffiti wall

V2-Only Endpoints (New in V2)

These endpoints are only available in V2 and have no V1 equivalent:
CategoryV2Notes
Validator MetricsPOST .../validators/metadataValidator metadata (Pro)
Validator MetricsPOST .../validators/apy-roiAPY and ROI calculations
Validator DutiesPOST .../validators/upcoming-duty-slotsPending API: the beaconcha.in team is working on this API.
Validator DutiesPOST .../validators/sync-committee-periodsSync committee period history
Sync CommitteesPOST .../sync-committee/validatorsPending API: the beaconcha.in team is working on this API.
BlocksPOST /api/v2/ethereum/blockBlock overview
BlocksPOST .../block/rewardsBlock rewards breakdown
NetworkPOST /api/v2/ethereum/configPending API: the beaconcha.in team is working on this API.
NetworkPOST /api/v2/ethereum/performance-aggregateNetwork-wide performance aggregate
EntitiesPOST /api/v2/ethereum/entitiesStaking entities overview (Pro)
EntitiesPOST .../entity/sub-entitiesEntity sub-entities (Pro)

Migration Example: Validator Lookup

Before (V1)

curl 'https://beaconcha.in/api/v1/validator/1?apikey=YOUR_API_KEY'

After (V2)

curl -X POST 'https://beaconcha.in/api/v2/ethereum/validators' \
  -H 'Authorization: Bearer YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "chain": "mainnet",
    "validator": {"validator_identifiers": [1]}
  }'
Key changes in this example:
  1. GET becomes POST with a JSON body
  2. The validator index moves from the URL path into the validator object in the request body
  3. Authentication moves from query parameter to Authorization: Bearer header
  4. You must specify the chain explicitly

Migration Example: Rewards Data

Before (V1)

curl -H 'apikey: YOUR_API_KEY' \
  'https://beaconcha.in/api/v1/validator/1/incomedetailhistory'

After (V2)

curl -X POST 'https://beaconcha.in/api/v2/ethereum/validators/rewards-list' \
  -H 'Authorization: Bearer YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "chain": "mainnet",
    "validator": {"validator_identifiers": [1]},
    "page_size": 10
  }'
V2 rewards data includes a detailed breakdown by duty type (attestation, sync committee, proposal) with reward, penalty, and missed reward amounts.

Authentication Changes

V1 supported both query parameter and header authentication:
# V1 - query parameter
curl 'https://beaconcha.in/api/v1/validator/1?apikey=YOUR_API_KEY'

# V1 - header
curl -H 'apikey: YOUR_API_KEY' 'https://beaconcha.in/api/v1/validator/1'
V2 uses only Bearer token authentication:
# V2 - Bearer token (only method)
curl -H 'Authorization: Bearer YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -X POST 'https://beaconcha.in/api/v2/ethereum/state' \
  -d '{"chain": "mainnet"}'
The same API key works for both V1 and V2. You do not need a new key to start using V2.

Pagination Changes

V1 uses offset-based pagination:
# V1 - offset pagination
curl 'https://beaconcha.in/api/v1/validator/1/balancehistory?offset=100&limit=25&apikey=YOUR_API_KEY'
V2 uses cursor-based pagination. The first request omits the cursor, and subsequent requests use the cursor value from the paging object in the previous response:
# V2 - first page
curl -X POST 'https://beaconcha.in/api/v2/ethereum/validators/balances' \
  -H 'Authorization: Bearer YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "chain": "mainnet",
    "validator": {"validator_identifiers": [1]},
    "page_size": 25
  }'

# V2 - next page (use cursor from previous response)
curl -X POST 'https://beaconcha.in/api/v2/ethereum/validators/balances' \
  -H 'Authorization: Bearer YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "chain": "mainnet",
    "validator": {"validator_identifiers": [1]},
    "page_size": 25,
    "cursor": "eyJlcG9jaCI6MzQ3NTY2fQ=="
  }'
See the Pagination Guide for full details on cursor-based pagination.

Rate Limit Considerations

When migrating, your rate limit behavior depends on your subscription type:
  • Legacy plans (Sapphire, Emerald, Diamond): V1 and V2 use separate rate limit buckets. Your V1 quota is unaffected by V2 usage.
  • Current plans (Hobbyist, Business, Scale): V1 and V2 share a single rate limit bucket.
See the Rate Limits guide for full details.