SonarX

Real-timeblockchain data API

The same indexed chain data we put in a datashare, answered one request at a time. Blocks, transactions, logs and traces over REST, with an API key and no warehouse in the path, plus low-latency read and archive endpoints for applications that need chain state directly.

Coverage

Live on major EVM chains

More chains
Added on request
Interface
REST, key authenticated
Reads
Current state and archive

Application teams read chains like these through the endpoints for wallet views, enrichment and support lookups, without operating nodes of their own. Other chains are added on request: the API serves whatever SonarX indexes, EVM or not. Coverage per chain is listed on the chain coverage page.

Resources

The data endpoints

Responses carry the same normalized fields as the corresponding tables, so a service reading the API and a job reading the warehouse do not disagree about what a transaction looks like. Ethereum, Base and Arbitrum all answer on the same paths with the same shapes.

  • BlocksBy number or by range, with the header fields already parsed.
  • TransactionsBy hash, by block, or by address, with receipts alongside.
  • LogsFiltered by contract, topic or block range.
  • TracesInternal calls in the same normalized shape as our tables.
  • Transfers and state diffsOn the chains where we index them.

Node access

Low-latency read and archive

Alongside the data endpoints we offer full-node read access and archive read access. Running your own archive fleet is the expensive part of most chain integrations, and it is rarely the part that differentiates the product you are building.

  • Read

    Read endpoints answer against current chain state, for the calls an application makes constantly.

  • Archive

    Archive endpoints answer against any historical block, so a question about state a year ago does not need an archive node of your own.

  • Both are built for latency rather than throughput. Bulk export is what a datashare is for.
  • Same key, same authentication and same error shapes as the data endpoints.

Use cases

What teams build with it

  • Application backends that need chain reads without operating nodes.
  • Dashboards and internal tools that query a handful of blocks or addresses at a time.
  • Enrichment services that resolve a transaction or log on demand.
  • Historical lookups at a specific block for reconciliation and support.
  • Filling gaps in a warehouse workflow where one row is needed immediately.

Get started

Talk to us about API access

API access is set up with our team rather than self-served, so we can size rate limits and confirm which chains you need before you build against it.