|Authentication||Basic Auth or Query parameter|
|Data latency||Real time: 2 blocks, Batch: 30 minutes|
|Rate limits||See Rates Card|
|Supported networks||See full list|
|Support||API FAQs, Discord|
What's the Unified API
Covalent is a hosted Web3 data provider offering a Unified API to bring full transparency and visibility to assets across all blockchain networks.
Accessing blockchain data at scale can be challenging. Common approaches such as running or using public blockchain nodes can be expensive and limiting. Other solutions require writing custom and complex SQL queries and sometimes developers have to wait for data to be indexed and available These data challenges are friction points which hinder Web3 development and adoption.
The Covalent API is RESTful and provides a unified approach to fetch blockchain data with a consistent request and response object format. For example, a user can fetch all the token balances for a wallet address across any supported blockchain by changing the unique blockchain name or id path parameter in the URL:
GET https://api..../v1/eth-mainnet/address/0xfc...71de/balances_v2 GET https://api..../v1/bsc-mainnet/address/0xfc...71de/balances_v2
This unified approach enables developers to implement the Covalent API once and automatically benefit from newly supported chains, endpoint performance upgrades and other improvements.
How does the Unified API compare to JSON-RPC alternatives?
The JSON-RPC layer is a 'point-query' interface where data requests for a block or transaction is executed one object at a time. Users are unable to query multiple objects at once and can't batch export data. This bottleneck is a primary reason why JSON-RPC doesn't scale when extracting on-chain data and why tools like the Covalent API help address those shortfalls.
What are the Use Cases of the Unified API?
The Covalent API supports a broad range of Web3 data use cases including:
How can you extend the Unified API?
Launching soon will be tooling that enables developers to extend the Unified API by creating custom API endpoints referred to as (Class C) endpoints.