Subscan API

Subscan API is tracked as an on-chain state and governance source for Polkadot coverage. Explorer and indexed Substrate chain API for accounts, extrinsics, governance, staking, and asset data

Coming soonGateway available

At a glance

Decision summary

Best for
Substrate account and extrinsic lookups
Watch out for
Generic EVM RPC workloads
Auth
API key
Pricing
Freemium
Agent actionability
Requires revalidation
PubFi gateway
PubFi gateway route documented; reverify before live use
Last verified

Provider-sourced facts

Primary query
subscan api Source
Primary coverage
Substrate accounts, extrinsics, governance, staking, and asset data Source
Discovery category
On-chain state and governance Source
Auth model
API-key authentication is required for live Subscan API use Source
Commercial fact
Free API access is documented with one API key and a 5 req/sec limit; paid-plan pricing is not public in the support article Source
PubFi status
PubFi gateway route documentation exists for Subscan; upstream account, auth, and route limits still apply Source

Best fit and tradeoffs

Best for

  • Substrate account and extrinsic lookups
  • Polkadot and parachain governance monitoring
  • They want authenticated indexed access to Polkadot and Substrate ecosystem data without standing up a custom indexing stack first.
  • They need explorer-style reads for governance monitoring, account history, staking state, extrinsics, and assets across multiple substrate-based networks.
  • They want a faster path to workflow-ready reads than a build-your-own indexing approach usually offers.

Watchouts

  • Generic EVM RPC workloads
  • Market-wide price aggregation
  • Subscan is optimized for its published indexed API surface, so teams that need custom indexing logic or custom schema control may outgrow the default product shape.
  • You cannot directly test live API responses before registering and generating an API key, which adds real onboarding friction even for early evaluation.
  • Route usability depends on the documented effective networks for each interface, so teams cannot assume that an endpoint name automatically means the same coverage across all supported networks.

Why teams choose it

Subscan API is an indexed Substrate and Polkadot data API for teams that need account, extrinsic, governance, staking, and asset reads without operating their own indexer first. The official support site presents Subscan as an authenticated API surface for more than 70 substrate-based networks, which makes it useful when a product team wants explorer-style data access quickly.

For Discovery readers, the key distinction is that Subscan should usually be evaluated as a published indexed API product rather than as a customizable indexing framework. It is often the faster starting point for workflow-driven monitoring use cases, but teams still need to account for registration, API-key issuance, per-route network applicability, and the fact that public paid-plan pricing is not fully exposed in the support article.

Capability summaries

Subscan API on-chain state coverage

Current
Category
On-chain state
Public status
Requested
Auth requirement
API key
Procurement state
Free Requires Auth
Coverage
Polkadot
Output contracts
Chain State Record

Subscan API governance coverage

Current
Category
Governance
Public status
Requested
Auth requirement
API key
Procurement state
Free Requires Auth
Coverage
Polkadot
Output contracts
Governance Record

PubFi gateway status

PubFi gateway route documented; reverify before live use

The gateway readiness catalog has a production-callable PubFi route for this source, but the Discovery source profile is not current. Agents should reverify upstream docs, commercial terms, and gateway behavior before live use.

Route pattern
/api/gateway/subscan/{network}/{endpoint...}
Network convention
The network segment maps to the upstream Subscan chain host, such as polkadot or acala.
PubFi auth headers
Authorization: Bearer <PubFi API key> or X-PubFi-Api-Key: <PubFi API key>
Gateway docs
Documentation

Current block time

GET polkadot
Gateway path
/api/gateway/subscan/polkadot/api/now
Upstream path
/api/now
curl
curl --location 'https://pubfi.ai/api/gateway/subscan/polkadot/api/now' \
  --header 'Authorization: Bearer <PubFi API key>'

Account tokens

POST polkadot
Gateway path
/api/gateway/subscan/polkadot/api/scan/account/tokens
Upstream path
/api/scan/account/tokens
curl
curl --location 'https://pubfi.ai/api/gateway/subscan/polkadot/api/scan/account/tokens' \
  --header 'Authorization: Bearer <PubFi API key>' \
  --header 'Content-Type: application/json' \
  --data '{
  "address": "13YMK2efcJncYrXsaJCvHbaaDt3vfubdn75r4hdVxcggU4n2"
}'

Account tokens on Acala

POST acala
Gateway path
/api/gateway/subscan/acala/api/scan/account/tokens
Upstream path
/api/scan/account/tokens
curl
curl --location 'https://pubfi.ai/api/gateway/subscan/acala/api/scan/account/tokens' \
  --header 'Authorization: Bearer <PubFi API key>' \
  --header 'Content-Type: application/json' \
  --data '{
  "address": "13YMK2efcJncYrXsaJCvHbaaDt3vfubdn75r4hdVxcggU4n2"
}'

Implementation notes

Docs

Medium

Treat account registration and API-key issuance as part of the implementation path, not as a later commercial detail, because live response validation cannot begin before those steps are complete.

Coverage

Medium

Verify the documented effective network scope for each target route before integration work starts, because endpoint usability should be checked together with per-network applicability rather than assumed globally.

Rate limits

Medium

Use the official free-plan limit as a planning constraint for prototypes and keep paid throughput assumptions out of production estimates until the target plan is confirmed.

Schema

Low

Design adapters around the specific endpoint response shape you use instead of assuming account, governance, staking, and asset routes all expose the same pagination and field conventions.

Auth

Medium

When routing through PubFi, keep the PubFi key and any upstream Subscan credential handling separate in your implementation notes so public source evaluation does not turn into a false claim of universal gateway availability.

Use case candidates

  • Track account activity across Substrate chains
  • Read governance and staking state for Polkadot ecosystem apps

Comparison snapshot

Against custom indexing platforms, Subscan is usually the better choice when governance monitoring, account history, and staking reads need to ship quickly through a ready-made indexed API surface. Teams that need deeper control over how data is indexed and queried should still evaluate whether a framework-led approach is the better fit.

PubFi friction reduction

Auth

Source friction
Official Subscan support docs require account setup and API-key use before live API testing.
PubFi relief
The Discovery page separates source evaluation from PubFi gateway status and points teams to the PubFi quickstart only where gateway documentation exists.

Rate Limiting

Source friction
Official support docs list a free API rate limit while paid-plan limits are not safely projectable from public text alone.
PubFi relief
PubFi keeps public rate-limit copy status-aware instead of inventing unsupported paid throughput claims.

FAQ

What is Subscan API used for?

Subscan API is a candidate source for indexed Substrate account, transaction, governance, staking, and asset reads.

Is Subscan API available through PubFi?

PubFi publishes Subscan gateway documentation, but teams should still treat upstream API keys, account setup, supported network scope, and provider limits as part of implementation planning.

When should a team compare Subscan with SubSquid?

Compare Subscan with SubSquid when the decision is between consuming a ready-made indexed API and building a more customizable indexing pipeline.