Glassnode API integration: where on-chain data is lost
Glassnode API integration starts not with obtaining a key but with the design of the flow: connection to blockchain data occurs either through a subscription to new blocks or through periodic polling of metrics by addresses and aggregates.
Both modes give a correct picture only with a continuous connection and explicit handling of chain reorganizations — the rest of the time the data looks intact, although it is already lost.
The first failure is missing blocks when the connection drops.
The subscription restores silently, without backfilling the missed range of heights, and a hole remains in the report: flow metrics such as the number of active addresses per day are understated, and recalculation from incomplete data reproduces the same error. It can only be found after the fact by reconciling with your own node.
The second class is wallet balance discrepancy after a reorganization.
A transaction already counted as confirmed goes into an orphaned branch, while the aggregate for the address retains its previous value: in the risk model, such an address passes as solvent until the first reconciliation.
The third problem is latency. Manual metric export lags behind the network state by hours, so limits and stop factors are recalculated based on yesterday's snapshot.
The cost of all three failures is the same: figures in reporting stop reconciling with node data, and trust in them is lost before the cause is discovered. We explain how this is closed at the level of collection architecture.
What a well-established network metrics pipeline delivers
A blockchain network metrics stream is only as useful as it is fresh.
The collector polls the source at a step matching the metric aggregation window and stores the timestamp of the last successful response: the dashboard shows the current state of the network, not a snapshot lagging by a day.
If a partial response arrives, the window is marked as incomplete and re-requested rather than going into storage with a hole.
Transaction history integrity rests on idempotent writes: a metric is tied to an entity — time window pair, so re-loading the same range does not create duplicates or break the series.
Backfilling runs as a separate pass from the boundary of already collected data, and the missed interval is closed automatically after a failure.
Metric collection resilience is behavior under failures, not the absence of failures.
Retries with increasing backoff, request rate limiting, a local cache of last values, and a queue of unprocessed windows on disk: when the source is unavailable, data is not lost but processed once access returns.
We treat integration with Glassnode as with any external source — with a data schema, response contract, and input quality checks.
The result is measurable: the delay between a network event and its appearance on the dashboard is minutes, the share of missed windows in history is zero, and the class of failures where re-loading corrupted already collected data is completely eliminated.
Connecting to Glassnode: polling, subscription, replica
The data retrieval mode determines what the product can do: an analytics dashboard tolerates a delay of minutes, while an alert on wallet fund movement does not.
Therefore the choice is made not as “which method is better” but according to the required freshness and request volume. Below are three working schemes and their limitations.
Comparison of modes
| Mode | When it fits | Limitations |
|---|---|---|
| Periodic metric polling | Reports, dashboards, recalculation of historical snapshots; a delay of minutes is acceptable | Request rate ceiling, limit consumption grows with the number of addresses; reaction to an event is always delayed |
| Blockchain event subscription | Alerts, wallet monitoring, real-time deposits and withdrawals | A receiver with a queue and redelivery is needed: without a buffer, events are lost during a failure |
| Local node replica | Large volumes, query privacy, custom derived metrics | Own infrastructure and synchronization; under load, the replica lags behind the network |
In practice, the schemes are combined: subscription covers urgent events, polling covers regular snapshots and reconciliation, replica covers heavy queries and anything that should not go outside.
Once a day, we run reconciliation of the replica against an external source on control metrics — a discrepancy above the threshold means lag or indexing failure, and we switch calculations to data from polling while the replica catches up. Such a setup provides predictable freshness without a constant increase in the number of requests.
Implementation stages: from audit to operation
On-chain data collection rarely breaks immediately — discrepancy accumulates: some addresses fall out of the sample, a metric is calculated over a different window, a block reorganization distorts history retroactively.
Therefore implementation proceeds in fixed stages, where each next stage relies on the verified result of the previous one, not on assumptions.
-
Data source audit. We inventory which metrics are already collected, from which sources, at what frequency, and where duplicates and gaps are. We fix the list of addresses and contracts that the product actually needs — everything else does not enter the sample.
-
Data flow schema. We describe the path from an API request to the data mart: who the consumer is, where the cache is, where the raw response is stored, how request rate limits and retries on failure are handled.
-
Access setup. We separate environments, issue separate keys to services, configure rotation and read-only permissions — a leak of one key does not open access to the others.
-
Enrichment implementation. We bring responses to our own model, normalize addresses and units of measurement, and handle partial and empty responses as a normal case, not as an error.
-
Historical data validation. We run calculations on past periods and reconcile with an independent source or our own node copy. We analyze discrepancies down to the cause — usually a different aggregation interval or unaccounted internal transfers.
-
Monitoring. We set alerts for data freshness, error rate, and update latency: a failure is visible before a user notices it.
-
Handover to operation. We provide documentation on flows and metrics, a dependency update procedure, a rollback plan, and training for the team that will continue to run the solution.
What we hand over: schemas, access rights, procedures
After launch, you are left not with a set of scripts but with a package that the team can use to operate and develop data collection without us. Below is exactly what we hand over and why each artifact is needed in daily work.
- Collection configurations — list of metrics, polling frequencies, aggregation windows, and request limits to Glassnode API, with notes on what to change as load grows.
- Data flow schema — the path from request to storage: where buffers are placed, how retries and discrepancies between sources are handled.
- Data access rules — roles and scopes, the procedure for issuing and revoking keys, storage of secrets separately from the repository, rotation.
- Metric collection procedure — mandatory and optional sets, recording of gaps, thresholds after which collection is considered incomplete.
- Integration documentation — field and type descriptions, metric dictionary, examples of requests and responses, schema versioning procedure.
- Failure response procedure — incident levels, response times, what is considered degradation and what is a collection stoppage.
- Failure recovery instructions — rollback to the last consistent point, backfilling of the missed range, convergence check.
Separately, we hand over a test environment with the same access rules: changes to metrics and frequencies are tested there, not on production collection.
Together with a responsibility matrix — who owns the configuration, who issues access, where to report problems — this removes dependence on a single person.
Case study: wallet analytics without losing history
The client is a wallet analytics service: addresses, balances, relationships between counterparties.
Collection went through its own indexing service, and when communication with the blockchain node dropped, confirmed blocks were not caught up: transaction history was broken, and balances diverged from the actual state of the network.
A separate pain point was chain reorganization: after rolling back part of the blocks, records remained from the previous branch and corrupted address samples.
We moved collection to Glassnode and rewrote the write pipeline: blocks and transactions are saved idempotently by hash, block height serves as the catch-up pointer, and after downtime the service reads the missed range itself.
Once a day, data is reconciled with our blockchain node by balance checksums and transaction count — discrepancies go into a report, not into client exports.
What changed
- Share of lost blocks: 6–7% on each disconnection → zero, catch-up happens automatically.
- History recovery after a disconnection: about 40 minutes of manual operations → 2–3 minutes without engineer involvement.
- Discrepancies during reconciliation with the node: up to 2% of samples → less than 0.1%, each one investigated individually.
For the client's team, this means that wallet analytics no longer depends on the stability of the channel to the node, and disputed balances no longer require manual recalculation.
How does event subscription differ from periodic polling?
The difference is who initiates data transfer. With a subscription, the source, for example Glassnode, sends an event itself as soon as a new block appears in the network or a transaction occurs on a tracked address.
With periodic polling, we request a snapshot on a schedule and compare what changed. This choice determines data update latency, load on the data source, and the maintenance overhead of collection.
Subscription latency equals event delivery time — seconds — and it does not grow with the number of tracked addresses.
For polling, latency averages half the interval: if you want fresher data, poll more often, and each cycle is another request across all addresses, even if there was no movement on them.
Load and maintenance diverge in the opposite direction. Subscription requires a constantly live connection: monitoring for disconnections, reconnection with context recovery, and accumulation of events during a failure.
Polling is simpler — it survives a restart and is deduplicated by cursor — but with hundreds of addresses it turns into a stream of empty responses.
| Criterion | Event subscription | Periodic polling |
|---|---|---|
| Update latency | seconds, independent of the number of addresses | half the polling interval |
| Load on source | only real events | grows with frequency and number of addresses |
| Collection maintenance | disconnections, reconnections, accumulation | restart, cursor, deduplication |
| When it fits | notifications about threshold events | reports, reconciliation, history backfill |
By default, we design a hybrid: subscription for prompt reactions, polling for state reconciliation and backfilling missed periods. Latency remains in seconds, and data collection does not depend on whether the connection survives an overnight disconnection.
Common technical questions about connecting to analytics
Before starting integration, engineers ask roughly the same questions: how the analytics layer behaves under load, what happens when limits are exhausted, and how to make sure metrics have not drifted after a failure.
Below are answers on four key points that most often determine the reliability of working with Glassnode and any other on-chain data source.
How do you avoid hitting API request limits?
We calculate the budget in advance: number of metrics, update frequency, number of tracked addresses and contracts. Then a cache with different time-to-live values: rare indicators update less often, fresh ones more often.
When a request fails due to a limit, it is retried with increasing delay and jitter, so a burst does not turn into a storm of failures.
Can historical data be rebuilt?
History is loaded in chunks with a time cursor and written so that a repeated run does not create duplicates. Rebuilding runs in a separate environment and does not interfere with the operational metric stream — the period and set of indicators can be refined retroactively.
How is data integrity verified?
We reconcile checksums by intervals, look for gaps and anomalous spikes relative to neighboring points, and compare aggregates with an independent source. Discrepancies go into a report and do not reach the data mart on which decisions are built.
What happens when the source is unavailable?
A backup metric source is connected based on availability checks — a second provider or your own node with an indexer.
When the primary source returns, priority switches back automatically, and data from the downtime period is marked as incomplete so that analytics does not draw conclusions from gaps.
Let's discuss the task and come back with an estimate and plan
An accurate estimate and work plan come from specifics, not from general wishes.
Therefore the first step of cooperation is a review of the integration task with the engineer who will lead it: he asks questions, you answer the ones you already have, and we formulate the missing data collection requirements together.
What you send in return so that the estimate is accurate:
- which networks and address types are in focus, including labels for exchange and custodial wallets;
- the list of metrics on which signals are built, and the thresholds at which they trigger;
- depth of historical exports and update frequency: one-time reconciliation or a continuous stream;
- how data reaches consumers — database, regular report, monitoring panel, notifications;
- access requirements: who issues keys to the source, where they are stored, whether there are request rate limits;
- examples of manual exports so that we reproduce your calculation logic rather than reinventing it.
Based on the review, we come back with an estimate and work plan: the composition of stages, what we do and what remains on your side, checkpoints, and the acceptance procedure.
The first verifiable result is usually small — connection to the source and reconciliation of calculations on control addresses, so that you see the figures converge before the main development.