Account & Token APIs

Common parameters (when enabled):

Many Solana read endpoints support a shared set of knobs.

Common request parameters

This page focuses on account state and SPL token holdings.

Acceso’s Solana API exposes wallet and token state through normalized, production-ready schemas. It abstracts raw Solana RPC quirks and upstream instability.

• commitment: processed | confirmed | finalized

• min_context_slot: avoid serving data older than a known slot

• include_metadata: enrich SPL tokens with name/symbol/decimals (route-dependent)

If you need strongest consistency, use commitment=finalized. Expect higher latency.

Primary route (documented in examples):

Account reads answer: “does this address exist, who owns it, and what is its native balance?”

Account data

• GET /v1/solana/account/<ADDRESS>

Account responses are normalized for application logic. Common fields include:

What you typically get

• address

• exists (or an equivalent “not found” signal)

• lamports and sol (decimal-normalized)

• owner_program (program id)

• executable

• rent_epoch (when applicable)

• slot / block_time for the read context (when exposed)

Example: fetch a wallet account

curl -sS \
  -H "Authorization: Bearer $ACCESO_API_KEY" \
  "https://<YOUR_ACCESO_API_HOST>/v1/solana/account/<ADDRESS>?commitment=finalized"

Example: account response (shape)

{
  "success": true,
  "data": {
    "address": "Fh8...A1",
    "exists": true,
    "lamports": "1234500000",
    "sol": 1.2345,
    "owner_program": "11111111111111111111111111111111",
    "executable": false
  },
  "meta": {
    "request_id": "req_1c2d3e",
    "timestamp": 1765939200
  }
}

Existence semantics

Solana addresses can be “valid” but have no on-chain account. Deployments typically handle this as either:

• 200 with exists=false, or

• 404 with a structured error.

Do not assume one behavior unless your deployment contract states it.

Token holdings (SPL)

Holdings typically provide:

Normalization guarantees

Acceso parses token accounts and produces an aggregated holdings view.

Token holdings answer: “what SPL mints does this wallet hold, and how much?”

• Aggregation across multiple token accounts per mint.

• Decimal-aware conversion (raw_amount → ui_amount).

• Optional metadata enrichment (symbol/name/decimals), when configured.

1. Fetch account state for SOL balance and ownership context.

2. Fetch token holdings for SPL balances.

3. Cache token metadata aggressively (slow-changing).

Example workflow: wallet portfolio snapshot

Example: token holding object (shape)

{
  "mint": "So11111111111111111111111111111111111111112",
  "raw_amount": "1000000000",
  "decimals": 9,
  "ui_amount": 1.0,
  "token_accounts": 2,
  "metadata": {
    "symbol": "SOL",
    "name": "Wrapped SOL"
  }
}

Caching and freshness

Caching is route-dependent:

• Hot reads may be cached for short TTLs to protect upstream RPCs.

• Token metadata is usually cached longer and deduplicated across requests.

If your use case is latency-sensitive, prefer fewer, richer calls over many small calls.