Page cover

Network, Metadata & Historical Data APIs

This page covers infrastructure signals, token metadata, and historical access patterns. Use it when you need context, enrichment, or time-series data.

Common request parameters

Many routes in this category support the same knobs:

  • commitment: processed | confirmed | finalized

  • min_context_slot: avoid returning data older than a known slot

  • start / end: epoch seconds for historical windows (route-dependent)

  • limit / cursor: pagination for long time ranges (route-dependent)

Network-level data

What you typically get

Network state endpoints help you reason about freshness, finality, and operational context.

  • Head slot (and block_height when exposed).

  • Head block_time estimate (best-effort).

  • Cluster health signals (ok / degraded) when available.

  • Optional per-commitment head slots (processed vs finalized), route-dependent.

Example: fetch the current network head (shape)
curl -sS \
  -H "Authorization: Bearer $ACCESO_API_KEY" \
  "https://<YOUR_ACCESO_API_HOST>/v1/solana/network/head?commitment=finalized"

Practical use cases

  • Correlate account activity with the chain head.

  • Gate “latest” reads behind a minimum slot.

  • Build basic monitoring without direct RPC calls.

Slots advance even when individual RPCs degrade. Treat network signals as advisory.

Token metadata resolution

Token metadata endpoints resolve descriptive and structural information for SPL tokens.

Metadata is best-effort and source-dependent. Expect partial results.

What you typically get

  • mint

  • decimals

  • symbol and name (when resolvable)

  • logo_uri / website / description (when resolvable)

  • supply (when exposed)

  • Authority references (mint/freeze), when available

Example: resolve token metadata (shape)

Caching characteristics

Metadata is cached and deduplicated:

  • It changes rarely.

  • It is shared across many wallets and feeds.

Client recommendation:

  • Cache metadata locally by mint.

  • Revalidate on a schedule, not per request.

Historical data access

Historical endpoints provide structured access to past blockchain data for analysis and reporting.

Supported capability patterns

  • Balance snapshots across time windows.

  • Time-windowed transaction activity with pagination.

  • Aggregated metrics (counts, volumes), route-dependent.

Expectations for analytical routes

  • Higher latency than “latest” reads.

  • Stronger preference for repeatability and stable pagination.

  • Backfills may be incremental depending on storage coverage.

Example: request a balance time series (shape)

Practical guidance

  • Use historical routes for reporting and analytics, not UI-critical reads.

  • Prefer cursor-based pagination for long ranges.

  • Treat timestamps as best-effort if you need strict slot ordering.

Last updated