Source adapters
Connect to venues, nodes, registries, issuers, documents, and reference providers while preserving native identifiers.
Digital Assets API: A Reference Architecture for Market and Onchain Data
Design dependable digital asset data interfaces with canonical identifiers, source provenance, time semantics, finality, normalization, streaming, indexing, authentication, and observable quality.
Scope note
An API architecture guide—not a live data product
DigitalAssetsWorld.com documents the data model and operating controls a useful interface should provide.
No unavailable functionalityThis site does not offer API keys, accounts, transaction submission, or live data endpoints. The examples below are educational schemas.
Start with meaning
A digital asset API is a contract about entities, sources, timestamps, calculations, and change. Returning JSON is easy; preserving identity, provenance, finality, and revision history is the hard part.
Separate data domains
Reference data, market observations, onchain events, entity labels, and derived analytics have different update rates, evidence, and confidence. The schema should keep those differences visible.
Data stack
Four layers from source to application
Normalization
Map canonical assets, networks, contracts, instruments, timestamps, units, statuses, and source provenance.
State & analytics
Index blocks, decode events, derive balances or metrics, reconcile history, and version calculation methods.
Delivery & quality
Expose REST, streams, webhooks, and bulk data with authentication, limits, replay, freshness, and incident status.
Canonical entity model
Identity before endpoints
A reliable API can distinguish the asset, its representation, the market where it trades, and the source that observed it.
| Entity | Durable fields | Common mistake |
|---|---|---|
| Asset | Canonical ID, issuer/namespace, lifecycle status, aliases | Using the ticker symbol as a unique key |
| Representation | Network, contract, native/wrapped/bridged relationship, decimals | Treating all versions as the same claim |
| Market | Venue, base, quote, product type, contract terms | Publishing “the price” without venue or method |
| Observation | Source time, receive time, status, raw value, provenance | Mixing raw and derived values without labels |
| Onchain event | Chain, block hash/height, transaction, log/instruction, finality | Reporting included data as permanently final |
Response contract
Every field should explain itself
GET /v1/assets/{asset_id}/observationsREFERENCE EXAMPLE
{
"asset": {
"id": "asset:canonical-id",
"network": "network:namespace",
"contract": "0x…"
},
"observation": {
"source": "venue-or-ledger",
"event_time": "2026-10-19T12:00:00Z",
"received_time": "2026-10-19T12:00:00.420Z",
"status": "finalized"
},
"method": {
"type": "source_observation",
"version": "1.0"
},
"revision": 0
}Time fields
Separate event time, source publication time, provider receive time, calculation time, and revision time. Use explicit UTC timestamps and document interval boundaries.
Provenance fields
Name the venue, ledger, registry, issuer, or provider. Derived metrics should identify the source set, filters, conversion path, and methodology version.
Status fields
Represent pending, included, confirmed, finalized, failed, dropped, replaced, stale, preliminary, corrected, and unavailable states without using a misleading zero.
Delivery choices
REST, WebSocket, indexers, and webhooks
REST
Best for reference resources, snapshots, history, pagination, reproducible requests, and straightforward retries.
WebSocket
Best for continuous updates when clients can manage subscriptions, sequence numbers, heartbeats, gaps, and reconnects.
Onchain indexing
Best for decoding blocks, logs, calls, and protocol state into queryable entities tied to a chain reference.
Webhooks
Best for selected notifications with signed delivery, unique event IDs, retries, and a canonical retrieval endpoint.
Bulk delivery
Best for large historical datasets, research, reconciliation, and workloads where streaming overhead adds little value.
Hybrid recovery
Load a snapshot, apply streaming deltas, detect gaps, reload from a known point, and reconcile against history.
Reliability
Observe the data—not just the servers
Freshness and completeness
Track source timestamps, chain height, processing lag, sequence gaps, duplicate rates, null spikes, outliers, and reconciliation differences.
Versions and corrections
Use stable schemas, deprecation windows, calculation versions, historical corrections, and visible revision status. Silent restatements break auditability.
Safe failure
A client should know whether no event occurred, the source was unavailable, the provider lagged, or the query was incomplete. Error responses need stable codes, request IDs, and retry guidance.
FAQ
API questions
Does DigitalAssetsWorld.com operate a public API?
No. This page is an educational architecture guide and does not advertise an available API key, endpoint, account, or data service.
Why are ticker symbols not enough?
Symbols can collide, change, or be reused across networks and wrapped versions. A durable identifier should include a canonical asset ID and relevant network, contract, issuer, venue, or instrument fields.
When should an application use WebSocket instead of REST?
Use WebSocket when continuous low-latency updates justify maintaining session state and gap recovery. Use REST for resources, snapshots, history, and straightforward retries. Many systems combine both.