Skip to main content
POST
Withdrawal Slots

Authorizations

Authorization
string
header
required

Authorization header with value: Bearer YOUR_TOKEN. Refer to the API Keys section to create your API key.

Body

application/json
validator
Indices/Pubkeys · object
required

Free selectors available to all users:

  • validator_identifiers: One or more validator indices or public keys to filter by.
  • dashboard_id: Your beaconcha.in dashboard ID (requires a free account).

Premium selectors for Scale & Enterprise plans (https://beaconcha.in/pricing):

  • withdrawal: The validator's withdrawal credential or the Ethereum wallet address used for withdrawals.
  • deposit_address: The Ethereum wallet address used for the validator's deposit.
  • entity: The name of the assigned entity (e.g., "Lido", "Coinbase"). Optionally include sub_entity for more specific filtering. Matching is case-sensitive.

Note: The set of validators matched by deposit_address and withdrawal selectors is updated once per epoch (~6.4 minutes). Newly deposited validators may take up to one epoch to appear in query results.

Note: The set of validators matched by entity selector is updated once per day.

chain
enum<string>
default:mainnet

The Ethereum chain to query.

Available options:
mainnet,
hoodi
cursor
string
default:""

Cursor value for pagination. See our pagination guide for more details.

page_size
integer
default:10

The number of items to return per page.

Required range: 1 <= x <= 10
range
Unix Timestamp · object

Specify a time range using either Unix timestamps or epoch numbers. If left null, the API will query the entire available history of the selected validators.

stage_filter
enum<string>[] | null

Deposits and withdrawals progress through multiple stages as they move from the execution layer (EL) to the consensus layer (CL) and back. Each stage is associated with a specific slot, and filtering by these stages helps you pinpoint exactly when an event was queued, processed, or credited.

Stages:

  1. execution_layer_queued – The request is signaled on the execution layer.
  2. execution_layer_processed – The request is dequeued on the execution layer and enters the consensus layer queue or is immediately rejected.
  3. consensus_layer_queued – The request is recognized by the consensus layer, but not yet processed.
  4. consensus_layer_processed – The request is fully processed by the consensus layer and the funds are credited to the target validator or withdrawal address; or rejected.

How to use this filter:

  • Pass one or more stages as an array to include events observed in any of the selected stages. Omit the field (or pass an empty array) to include all stages.
  • If you just submitted a deposit or withdrawal on-chain, look for execution_layer_queued (initial signal), then consensus_layer_queued (picked up by CL), and finally consensus_layer_processed (final credit).
  • To find when a deposit is credited to your validator, filter by consensus_layer_processed.
  • To find when a withdrawal is credited to your address, also filter by consensus_layer_processed.
  • If the request is valid, execution_layer_processed and consensus_layer_queued will occur in the same slot, while consensus_layer_processed will occur in a later slot.
  • If the request is rejected, execution_layer_processed and consensus_layer_processed will occur in the same slot, while consensus_layer_queued will not occur at all.

Tip:
Use the appropriate stages to track the exact point in the lifecycle of your deposit or withdrawal, depending on whether you care about when it was signaled, queued, or actually credited.

Available options:
execution_layer_queued,
execution_layer_processed,
consensus_layer_queued,
consensus_layer_processed
Example:

Response

Successful response.

Response containing detailed withdrawal information of the validators.

data
object[]
required
range
object
required

The time span actually covered by the returned results — from the first to the last matching data point — specified in slots, epochs, and Unix timestamps.

This reflects the data that was found, not the range that was queried. When no data is found, it falls back to the requested range, or to the full available history if no range was given.

paging
object