Moonlytics.io
Use cases / Developers

Developers and product teams

Build digital asset intelligence without integrating a set of fragmented data sources first — provided the cadence and coverage fit your problem, which is the first thing this page tries to help you decide.

The integration you are about to write

Every team that builds something on crypto data writes roughly the same code before they write any of their own.

the work before the product
# What you build when you integrate providers directly

  provider clients          x N
  identifier reconciliation  ← the part that is quietly wrong
  schema mapping             x N
  unit and timezone handling
  retry, backoff, rate limits
  historical storage
  gap and null handling
  freshness tracking

# Then, finally: your product.

None of it is hard in isolation. The problem is that identifier reconciliation — the one that decides whether your numbers are attached to the right asset — is the one that looks easiest and is not. 225 symbols in the registry are shared by 460 different assets, and a system that keys on tickers is wrong about all of them, silently.

What the layer replaces

  • Provider clients — one model instead of several APIs.
  • Identity reconciliation — resolved once, canonically.
  • Schema and unit mapping — documented canonical fields with stated units.
  • Time base handling — everything UTC, everything on a stated grid.
  • Historical storage — 6.7 million observations already retained.
  • Freshness accounting — measured per category.

Decide quickly whether this fits

Worth being blunt about, because the wrong fit wastes both sides' time.

Good fit
  • Dashboards, screeners, research tools
  • Asset discovery and comparison surfaces
  • Portfolio and watchlist context
  • Narrative and news monitoring
  • Retrieval context for AI features
  • Anything where hourly is fast enough
Wrong tool
  • Trading execution or order routing
  • Liquidation or settlement pricing
  • Sub-minute alerting on price
  • Order book depth or microstructure
  • On-chain balances or transaction tracing
  • Anything needing a real-time feed

What you would integrate against

The public API is in development

There is no self-serve endpoint or key issuance today. The canonical data model and the per-category documentation are complete and stable, so the design work can be done now; the interface is covered on the API page, including what it will not expose.

Design decisions to make now

These hold regardless of how you eventually consume the data, and getting them right up front avoids a migration:

  1. Model assets by canonical id. Store the symbol as a display attribute. Never let a ticker be a foreign key.
  2. Store observedAt with every value, and surface it in the interface. Users forgive stale data; they do not forgive stale data presented as current.
  3. Make nullable fields nullable in your schema. They are null in practice.
  4. Keep hourly and daily series in separate tables. Joining them into one wide row is the fill problem in disguise.
  5. Design an empty state for gaps. "No observation for this hour" is a normal condition, not an error.

Talk to us with a shape

The most useful first message describes what you are building, which categories you need, at what cadence, over which asset universe. That is enough to say honestly whether this layer fits — including saying it does not.

Describe your integrationRead the data model

Related