Programmatic access
An honest status page rather than documentation for something that does not exist yet.
Moonboard runs a backend that serves its own application. That is not the same as a public API product: there is no published contract, no documented authentication, no rate-limit policy, no versioning commitment and no stability guarantee. Publishing endpoint documentation for internal infrastructure would invite integrations that could break without notice.
When a public API exists, it will be documented on this page with its real endpoints, its real limits and its real terms. Until then this page says what is true.
Status by area
| Area | Status | Scope |
|---|---|---|
| Asset data | in development | Price, market cap, volume, volatility and dominance per tracked asset. |
| Scores | in development | The seven documented metrics per asset. |
| Social data | in development | Social volume, interactions, dominance and sentiment. |
| Historical series | in development | Observations over time. Constrained by the universe reconstruction problem. |
| News and topics | planned | Headlines, deduplicated, with asset associations. |
| Webhooks | planned | Push notification on threshold or state changes. |
| SDKs | planned | Thin client libraries. Only worth building once the surface is stable. |
| MCP server | planned | Structured tool access for AI agents. Nothing is running today. |
In development means work is underway and the data already exists internally. Planned means it is on the roadmap and nothing has been built. Neither means available.
What you can build with today
Two things are genuinely available and stable, and both are documentation rather than data:
- The methodology is fully specified. Every formula, threshold and cap behind the seven metrics is written out under methodology, at a level of detail that allows independent reimplementation on your own data. The score calculator is a working reference implementation.
- The field definitions are public.Data categories documents every input field, its units and its failure modes — enough to build a compatible data model before any API exists.
How the API is being designed
Stated in advance so the eventual shape is not a surprise, and so the constraints are visible:
- Percentile metrics need their universe. Four of the seven metrics are ranks against the scanned set. A response returning a rank without stating which universe produced it would be misleading, so universe metadata will accompany any scored response.
- Missing and zero must be distinguishable. Internally an absent social value becomes zero, which conflates "no data" with "no activity". An API should not propagate that ambiguity — it is the single most important thing to fix at the boundary.
- Cache semantics have to be explicit. Data refreshes on fixed cycles; a response should say how old it is rather than implying it is live.
- Redistribution is constrained. Upstream licences govern what can be passed on, which shapes what any API can offer and is why this takes longer than the engineering alone.
Access for AI agents
Structured access for autonomous agents is a deliberate design target rather than an afterthought. Agents doing market research, monitoring narratives or comparing assets need the same data with different affordances: predictable schemas, explicit units, and — most importantly — machine-readable statements of uncertainty.
An agent that cannot tell a percentile from an absolute score, or a missing value from a zero, will produce confidently wrong conclusions. That consideration is also why this domain documents limitations as prominently as formulas: the constraints are part of the data, not a disclaimer attached to it.
An MCP server is on the roadmap. None is running today, and no tool definitions are published, because publishing an interface for a server that does not exist would waste the time of anyone who tried to use it.
Registering interest
If you have a concrete use case, describing it helps prioritise what gets built first — particularly which fields matter and at what latency.
Write to office@neob.ai with the data you need and what you would do with it.
Related
- Data API statusThe same picture, focused on the API itself
- MethodologyEnough detail to reimplement the metrics
- Data categoriesField definitions and units
- Data pipelineWhat produces the data an API would serve