Blockchair Support and API Documentation

The Blockchair API provides access to data from 18 different blockchains. Beyond standard data retrieval, it supports advanced analytical queries including filtering, sorting, and aggregating blockchain data.

Common use cases include:

• Building multi-blockchain wallets (requesting transaction, address, and xpub data, or broadcasting transactions).
• Creating analytical services and visualizations.
• Tracking cold wallet integrity.
• Academic research.

Note on large data extraction: For bulk data extraction (e.g., all transactions over a specific period), use the Database dumps feature instead of the API. Dumps are available in TSV format for ingestion into your own database (e.g., PostgreSQL).

Blockchair API uses a cost formula to determine the weight of a request based on the number of entities requested.

• Single block requests (by height or hash): Cost is 1.
• Multiple block requests (comma-separated list): Cost is 1 + (0.1 * (entity count - 1)).

Example: Requesting 10 blocks costs 1 + (0.1 * (10 - 1)) = 1.9.

The database is organized into schemas based on the blockchain. Currently supported schemas are:

• bitcoin
• bitcoincash
• litecoin

Each schema contains the following tables:

• blocks
• transactions
• outputs

To inspect column descriptions for a specific table, use the \d command in psql (e.g., \d bitcoin.blocks).

Blockchair is a blockchain search and analytics service, not a wallet provider or a financial institution.

• Transaction Reversals: Blockchair cannot reverse transactions on public blockchains. Irreversibility is a fundamental property of cryptocurrency.
• Security/Phishing: Blockchair does not provide wallet services. If you have entered a 12-word passphrase into a website and lost funds, you have likely encountered a phishing site. Blockchair cannot recover these funds but can report such sites to authorities.

Blockchair API uses specific identifiers for different blockchains and second-layer tokens within its URL paths. Use the following tokens to construct your requests:

• BTC-based chains ({:btc_chain}): bitcoin, bitcoin-cash, litecoin, bitcoin-sv, dogecoin, dash, groestlcoin, zcash, ecash, or bitcoin/testnet
• Ethereum chains ({:eth_chain}): ethereum or ethereum/testnet
• Ripple ({:xrp_chain}): ripple
• Stellar ({:xlm_chain}): stellar
• Monero ({:xmr_chain}): monero
• Cardano ({:ada_chain}): cardano
• Mixin ({:xin_chain}): mixin
• Tezos ({:xtz_chain}): tezos
• EOS ({:eos_chain}): eos
• Cross-chain tokens ({:xchain_token}): tether, usd-coin, or binance-usd

Infinitable endpoints allow you to perform SQL-like operations (filtering, sorting, aggregating) on blockchain data. The endpoint structure is https://api.blockchair.com/{:table}{:query}.

Unlike dashboard endpoints, infinitable endpoints do not automatically search both the blockchain and the mempool; for unconfirmed data, you must explicitly use the mempool tables (e.g., {:chain}/mempool/transactions).

If no query is provided, the API returns the top 10 results using the table's default sorting (usually descending by ID).

https://api.blockchair.com/bitcoin/blocks
https://api.blockchair.com/bitcoin-cash/mempool/transactions

All timestamps returned by the API are in the UTC timezone using the format YYYY-MM-DD hh:ii:ss.

To convert these to an ISO 8601 format with a timezone, replace the space with a T and append Z.

Example: 2009-01-03 18:15:05 $\rightarrow$ 2009-01-03T18:15:05Z

Each API request consumes a certain amount of 'base request cost'.

• Base Cost: The cost applied when no additional parameters are included and default result limits are used.
• Variable Cost: Some endpoints use formulas where cost increases based on the number of entities requested. In these formulas, c represents the "number of requested entities" and d represents "depth" (specifically for xpub lookups).
• Example Formulas:
  • 1 + 0.1*c: A base cost of 1 plus 0.1 for every entity requested.
  • 1 + 0.001*c: A base cost of 1 plus 0.001 for every entity requested (used for mass balance checks).
  • 1 + 0.1*d: A base cost of 1 plus 0.1 for every unit of depth.

The Privacy-o-meter is a transaction scoring tool (currently available for Bitcoin) that evaluates how much privacy a transaction provides.

• Low Score (e.g., 0): Indicates a transaction where an analyst can easily distinguish between the recipient and the change address using heuristics. This often happens with round amounts or mismatched script types.
• High Score (e.g., 100): Indicates a transaction where it is difficult to distinguish the recipient from the change address, providing better privacy.

Note: A low score might also indicate a user is intentionally attempting to confuse forensics software.

Blockchain support is categorized by stability and data retention:

Support Status

• Full support: Stable and reliable.
• Beta mode: Possible instability (e.g., eCash).
• Alpha mode: Possible compatibility-breaking changes (e.g., Ripple, Stellar, Monero, Cardano, Tezos, EOS).
• Development mode: No guaranteed stability (e.g., Ethereum Goerli Testnet).

Historical Data Limitations

Most blockchains have full historical data. However, Ripple, Stellar, and EOS do not store full historical data. You may be unable to query old blocks or see old transactions for an address on these chains. Use the Available block ranges API endpoint to check which blocks are currently available for these specific blockchains.

Blockchair uses a "request cost" model where different requests consume different amounts of points based on the complexity and volume of data requested.

• Bulk requests: Requesting data for multiple items (e.g., 10 transactions) in one request is cheaper than making 10 individual requests.
• Cost tracking: The context array in every API response contains a request_cost field indicating the cost of that specific request.
• Premium users: Can track usage via the Blockchair control panel.