Skip to main content

Goldsky

Improve blockchain data API reliability and coverage

Talk to our team

What it is

Improving blockchain data API reliability means making sure the balances, transfers, token metadata and prices your app gets from a crypto data API keep arriving, cover every chain you need and match the chain, even when that API has an outage, hits rate limits or returns wrong balances.

Wallets, consumer apps and fintech backends depend on that data staying up because a single blockchain API provider going down, throttling them or dropping a chain leaves users looking at empty or wrong portfolio screens, and a backup API only helps if your app can already fail over to it.

You can improve blockchain data API reliability three ways: move your balances, transfers and token prices to Goldsky Feeds, keep your current API and fail over to Feeds when it errors or rate limits you, or cross-check its answers against Feeds.

Who it’s for

Wallet apps, consumer crypto and fintech apps, and custody and payments backends that read wallet balances, transfers and token prices from a third-party blockchain data API.

How moving your wallet data to Feeds works

The diagram follows a move from your current data API to Feeds, from listing the calls you make to switching your traffic over. Your setup may differ.

Your business, steps 1–2: List your callsEndpoints, chains and tokens in use
Your business, step 6: Compare with your APISame wallets, both sources
Goldsky, steps 3–4: FeedsRead balancesWith token metadata and USD prices
Goldsky, step 5: FeedsRead transfersPriced at transfer time
Your business, step 7: Switch traffic overService by service, at the pace asked
  • Goldsky

Ways to improve blockchain data API reliability and coverage

Moving replaces your current data API with Feeds. Failover keeps your API and calls Feeds only when it fails. Cross-checking leaves your API in the path and compares its answers with Feeds, which catches wrong balances rather than downtime.

Usual setupOption 1: Move to Feeds
Best for
Teams replacing a data API that keeps failing them
Products
Feeds
Your current API
Replaced by Feeds
What it fixes
Outages, rate limits, missing chains and wrong balances
Option 2: Fail over to Feeds
Best for
Apps that must keep showing balances when their main API fails
Products
Feeds
Your current API
Stays first; Feeds answers when it fails
What it fixes
Outages and rate limits
Option 3: Cross-check with Feeds
Best for
Spot checks and per-wallet comparisons against your current API
Products
Feeds
Your current API
Stays in the path; Feeds checks it
What it fixes
Wrong balances and dropped transfers, not downtime

Option 1: Improve blockchain data API reliability by moving to a new API

Your app reads wallet balances, transfers and token metadata and prices from Feeds in place of your current blockchain data API, after you check coverage and compare the two side by side.

When to move to a new blockchain data API

Outages, rate limits, missing chains or wrong balances at your current API keep reaching users, and you’d rather replace it than run two providers.

What you’ll need

  • Goldsky Feeds
  • A list of the endpoints, chains and tokens your app reads today
  • Access to the config or code where your services call the data API
  • A test environment to compare responses before switching

  1. List the data your app calls

    A move only keeps your app up if the new source serves everything your app asks for.

    Pull the endpoints, chains, token types and request volume from your logs or your provider’s usage report. A call you didn’t list is the one that breaks after the switch.

  2. Check each chain and token type is covered

    Missing chains are often why teams leave a data API, so the new one has to cover what the old one did and what it lacked.

    Match every chain and token type on your list against the new source’s coverage, including how far back its history goes on each chain. Anything not covered keeps a second source or waits.

  3. Read wallet balances

    Handled by Goldsky Feeds

    Balances are what users see first, so a wrong or missing one is the failure they notice.

    Each response has to cover every chain and token the wallet holds, with amounts in the token’s smallest unit so nothing is lost to rounding. A source that leaves out tokens it can’t price makes a portfolio look smaller than it is.

    Goldsky’s Feeds Balances endpoint returns the latest native and token balances of one wallet across the chains you ask for, with USD values and a total, and include_unknown_price=true keeps tokens that have no price.

    Query a wallet’s balances (opens in a new tab)

  4. Add token metadata and prices

    Handled by Goldsky Feeds

    A balance or transfer is only readable with the token’s symbol, decimals and a USD value next to it.

    Look up metadata and prices for the tokens you show in as few requests as you can, and treat a missing price as unknown rather than zero. Prices move between requests, so two reads seconds apart can differ.

    The Feeds Tokens endpoint returns the symbol, name, decimals, logo and current USD price of up to 100 tokens across chains in one request, and lists an unknown token with empty fields so every entry matches your request.

    Look up token metadata and prices (opens in a new tab)

  5. Read wallet transfers

    Handled by Goldsky Feeds

    History screens, notifications and deposit matching all run on the list of transfers in and out of a wallet.

    The history has to be complete for the window you ask about and stay stable as you page through it. A transfer reversed by a reorg should drop out, so don’t key stored rows on block numbers.

    The Feeds Transfers endpoint returns a wallet’s native and token transfers newest first, each with the USD value at transfer time, filtered by direction, time or block range.

    Query a wallet’s transfers (opens in a new tab)

  6. Compare the new source with your current API

    Running both side by side shows where they disagree before users see it.

    Send the same wallets to both sources and record each difference in balances and transfers. Prices can differ for honest reasons, so compare amounts first and USD values second.

  7. Switch traffic and honor rate limits

    Calls move only when each service points at the new API, and a busy API has to be called at the pace it asks for.

    Move service by service, and have your client wait the time a rate-limit or busy response gives before retrying. Retrying at once in a loop turns a short slowdown into an outage of your own.

What to know about moving to Feeds

  • Feeds covers native and fungible token balances, transfers and token prices, not NFTs or contract-specific events, so check each call you make has a match.
  • Balances are the latest only, so a screen that shows a past balance has to rebuild it from transfers.
  • The response schema is fixed and differs from your current API’s, so your code maps it to your own data model.
  • Each wallet is a separate request, and the API tells you when to slow down with a wait time rather than failing silently.

Option 2: Improve blockchain API availability with failover to a backup API

Your app keeps calling its current blockchain data API and sends a balance or transfer request to Feeds when that API errors, times out or rate limits you, then maps the answer to the same shape your app already uses.

When to fail over to a backup blockchain API

Your current data API works most of the time and you want to keep it, but its outages and rate limits shouldn’t take your app down with it.

What you’ll need

  • Goldsky Feeds
  • Your current blockchain data API
  • A client or proxy that can retry a request on a second API
  • A mapping from each API’s response to your own data model

  1. Keep your current data API as the first call

    A backup only takes over when the main source fails, so your app still asks the API it already uses first.

    Your client calls the current API first and knows the second source to try. If each service picks its own data API, one can fail over while another keeps calling the source that’s down.

  2. Notice when the current API fails you

    Failover only helps if your client can tell a failed request from a slow one before users notice.

    Set what counts as a failure: a timeout, a server error, a rate-limit response, or a chain or token the API doesn’t return. An answer with a balance that stopped updating can be a failure too, so check how fresh it is.

  3. Send the failed request to the backup API

    A request that failed at the main API has to be answered somewhere before the screen times out.

    Your client sends the same wallet, chains and tokens to the second API once, within the time your app can wait. Retrying the failing API in a loop adds load and delay without an answer.

  4. Answer from the backup API

    Handled by Goldsky Feeds

    The backup only helps if it returns the same data your main API should have.

    The second source has to cover the same wallets, chains and tokens, and tell your client clearly when to wait and when a request will never succeed. A backup that fails without saying why turns one outage into two.

    With Goldsky, Feeds answers balance and transfer requests for one wallet across its chains, and its errors carry a stable code and, when the request can succeed later, a Retry-After header.

    Feeds endpoints and errors (opens in a new tab)

  5. Map the answer to your data model

    Your screens and ledger expect one shape, whichever API answered.

    Convert chain names, token addresses, raw amounts and USD values from each API into your own model. A mapping that drops a field or misreads decimals turns an outage into wrong balances.

  6. Keep serving users through the outage

    The point of the backup is that users see balances and history as usual while the main API is down.

    Your app serves from whichever API answered and records which one it was, then returns to the main API when it recovers by the rule you set. Without that record, support can’t explain a balance that briefly looked different.

What to know about failing over to Feeds

  • Your client decides when to fail over and when to return; Goldsky runs the backup API.
  • The two APIs have different schemas, so the mapping to your own model has to be written and tested before an outage, not during one.
  • Failover covers only the chains and token types both sources serve.
  • The backup sits idle most of the time, so you pay for it mainly during outages and tests.

Option 3: Catch wrong balances by cross-checking your blockchain API

Your app calls Feeds for the same wallets’ balances and transfers that your current data API reports, and compares the two answers to find wrong balances and missing transfers.

When to cross-check your blockchain data API

Your worry is wrong balances, missing tokens or dropped transfers from your current API rather than downtime, and you want to catch them before users or auditors do.

What you’ll need

  • Goldsky Feeds
  • Your current blockchain data API
  • The list of wallets to check
  • A place to record mismatches and who follows them up

  1. Keep your current data API as the first call

    A backup only takes over when the main source fails, so your app still asks the API it already uses first.

    Your client calls the current API first and knows the second source to try. If each service picks its own data API, one can fail over while another keeps calling the source that’s down.

  2. Choose the wallets to check

    A second source is most useful on the wallets where a wrong answer costs most.

    Pick the wallets, chains and how often to compare them, such as treasury wallets daily and a sample of user wallets. Checking every wallet on every request costs more than the errors it catches.

  3. Read wallet balances

    Handled by Goldsky Feeds

    Balances are what users see first, so a wrong or missing one is the failure they notice.

    Each response has to cover every chain and token the wallet holds, with amounts in the token’s smallest unit so nothing is lost to rounding. A source that leaves out tokens it can’t price makes a portfolio look smaller than it is.

    Goldsky’s Feeds Balances endpoint returns the latest native and token balances of one wallet across the chains you ask for, with USD values and a total, and include_unknown_price=true keeps tokens that have no price.

    Query a wallet’s balances (opens in a new tab)

  4. Read wallet transfers

    Handled by Goldsky Feeds

    History screens, notifications and deposit matching all run on the list of transfers in and out of a wallet.

    The history has to be complete for the window you ask about and stay stable as you page through it. A transfer reversed by a reorg should drop out, so don’t key stored rows on block numbers.

    The Feeds Transfers endpoint returns a wallet’s native and token transfers newest first, each with the USD value at transfer time, filtered by direction, time or block range.

    Query a wallet’s transfers (opens in a new tab)

  5. Compare the two sources and chase breaks

    A mismatch only helps if someone finds out which source is wrong and fixes what depended on it.

    Your code compares raw amounts and transfer lists and records each difference with both answers. Someone on your team checks the chain itself and corrects any balance your app built on the wrong answer.

What to know about cross-checking with Feeds

  • Your current API stays in the request path, so this catches wrong data but doesn’t keep your app up during an outage.
  • A mismatch shows up only when you run the check, so pick a schedule that matches what a wrong balance costs.
  • The check covers the chains and token types both sources serve.
  • Your code does the comparing, so you decide what counts as a match and what to do with a break.

What you control

Your team
  • List the data your app calls
  • Check each chain and token type is covered
  • Compare the new source with your current API
  • Switch traffic and honor rate limits

Security and deployment

  • SOC 2 Type IIIndependently audited security controls.
  • Dedicated infrastructureSingle-tenant options for production workloads.
  • Data residencyCloud, on-premises or co-located.

More use cases that access chains reliably

Improve blockchain data API reliability with Goldsky

We’ll map it to your systems and show you what Goldsky runs, so your team builds the product, not the pipelines underneath it.

Talk to our team

© Endless Sky Inc. All rights reserved.

PrivacyTermsSecurity

System status