API reference

Paginated list of canonical entities, sorted by stable id. Every item carries its id, type, name, domain, and canonical path.

Resolve a single entity by its stable id, including its typed relationships (with direction and the entity on the other end).

Paginated list of typed, domain-tagged relationships. Filter by relation type, domain, or a specific from/to entity id.

Deterministic, non-semantic entity search over name, aliases, and id. Ranking is fixed (exact > prefix > alias > substring); there is no AI or fuzzy relevance.

Breadth-first traversal from a start entity, returning nodes and edges. Cycle-protected and bounded by maxDepth and limit; truncation is reported in warnings.

A grounded explanation of an entity — its description, its real graph relations, and its cited sources. Deterministic; no language model. Nothing is generated or invented.

Compares two entities by the real common ground between them — the entities they both connect to in the graph. Deterministic; no language model.

The shortest evidence path between two entities — a real chain of graph relations. Deterministic; no language model. 404 with an honest message when no path exists.

The full open-data catalogue — domain datasets and graph-level datasets — with real record counts, licenses, formats, and status.

Metadata for a single dataset by id, including its formats and (where a pre-generated file exists) real size and sha256.

The real citation registry — source-backed references across flagship entities and datasets, with DOIs where verified. Filter by type, source, entity, or dataset.

A single citation by id, including its type, DOI (if verified), links to entities/datasets/provenance, and formatted references.

Catalogue of verified scientific images with depicted object, capturing instrument, source, and license. Image files retain their upstream license.

The platform's source registry — every source's name, organisation, canonical URL, scope, authority type, and usage terms. The provenance behind every cited fact.

The registry of external providers the live-sky layer is designed to integrate. Every provider reports its integration status honestly: NOAA SWPC and NASA DONKI are connected, the rest are planned.

The computed Moon (method: computed — not a live provider feed), with its own honesty envelope. WITHOUT latitude/longitude: the global Moon phase and illuminated fraction. WITH latitude and longitude: location-aware moonrise, moonset, transit, topocentric position, phase, and horizon status for the date (polar and no-rise/no-set cases handled honestly). Location is only ever what you pass in — never inferred, geolocated, or stored.

Sunrise, sunset, solar noon, civil/nautical/astronomical twilight, day length, and a solar summary for an EXPLICIT location and date, deterministically COMPUTED from the public-domain NOAA Solar Calculator algorithm (method: computed — not a live provider feed). Polar day/night is handled honestly (null events + a status). Location is only ever what you pass in — never inferred, geolocated, or stored.

Computed, location-aware visibility for the naked-eye planets (Mercury–Saturn; Uranus/Neptune via ?planet): rise, set, transit, topocentric position, approximate magnitude, and conservative honest observing rules (method: computed — not a live provider feed). Positions use the public-domain NASA/JPL approximate planetary elements. Location is only ever what you pass in — never inferred, geolocated, or stored.

A computed COMPOSITE of the Sun & Twilight, Moon, and Planet engines (method: computed_composite — not a live provider feed): twilight/darkness summary and night type, Moon phase/rise/set/position and moonlight impact, ranked naked-eye planet visibility, and best observing windows for an EXPLICIT location and date. It invents no weather, cloud, seeing, ISS, aurora, meteor, or comet data; a sub-engine failure yields a null section plus a limitation. Location is only ever what you pass in — never inferred, geolocated, or stored.

The OpenAPI 3.1 description of every implemented endpoint. Planned endpoints are intentionally absent from the spec.

The typed contribution models the scientific review workflow accepts, with their required targets, review track, and quality impact. Read-only.

The contribution review-state machine: every state, its description, and its valid next states. Read-only.

The workflow's core principle, contribution types, review states, roles, and security model — everything a future contributor or client needs. Read-only.

Every current space-weather product from NOAA SWPC in one response: real-time solar wind and interplanetary magnetic field at L1, the propagated solar-wind series, observed and forecast planetary K-index, the R/S/G scales, the alert stream, the GOES X-ray flare state, the daily active-region report, the 10.7 cm radio flux, and the OVATION aurora forecast. Each product carries its own honesty envelope: provider, exact source URL, the provider's timestamp, freshness status, cache window, licence and limitations. A product that could not be read is present with a status and a reason and NO data key.

The GOES X-ray flare state, NOAA's daily numbered active regions with sunspot and magnetic classifications, the 10.7 cm radio flux, and NASA CCMC DONKI's curated flare and CME catalogues. The operational reading and the curated catalogue are separate keys and are never merged: they have different latencies and answer different questions.

The planetary K-index observed and forecast, the NOAA R/S/G scales, and SWPC's watch, warning and alert stream. Every Kp point carries a provenance field of observed, estimated or predicted, so no consumer has to guess whether a value is a measurement or a forecast.

NASA CCMC DONKI's catalogued solar flares, coronal mass ejections, geomagnetic storms and solar energetic particle events. An empty array means the catalogue held no records in the window, which is not the same as nothing having happened: DONKI is analyst-curated and lags events by hours.

Every live provider and product: its terms, authentication, documented rate limits, cache window, publication cadence, stale threshold, and what THIS server instance has actually observed of it — last attempt, last success, latency, consecutive failures and schema state. There is no uptime percentage and no reliability score: this deployment retains no operational history, so a long-run figure would be invented.

Every near-Earth object feed in one response: close approaches within 0.05 au over the next 60 days, the CNEOS Sentry impact-risk table, newly catalogued objects, and the Minor Planet Center's unconfirmed candidates. Close-approach times are TDB, not UTC. Impact probabilities are JPL's own and carry JPL's statement that they can be inaccurate by a factor of ten; AsteriaStar computes none of its own.

Near-Earth objects passing within 0.05 au over the next 60 days, each resolved against AsteriaStar's catalogue. Every approach carries its nominal distance in astronomical units, kilometres and lunar distances, the provider's 3-sigma minimum and maximum, and the 3-sigma uncertainty in the approach time — a nominal distance served without its bounds would turn a prediction with real error bars into a fact.

Everything the four live feeds currently say about one object. This endpoint does NOT proxy the provider: the designation comes from the request, and no value from a request is ever placed into a provider URL. The feeds are loaded from their own constant URLs and matched locally, so a designation absent here is absent from these four feeds — not from JPL's database.

Every satellite AsteriaStar tracks live, which is one: the International Space Station, from NASA Johnson Space Center's published operational ephemeris. The response states its own coverage explicitly rather than leaving it to be inferred from a single-element array.

Position, altitude, speed and measured nodal period for one satellite, plus `frameVerification` — the measured disagreement between this platform's coordinate transformation and NASA's own published equator-crossing longitudes from the same file. A consumer relying on these positions is entitled to see how far they can be trusted, measured rather than claimed. `current` is null when the published ephemeris does not cover the present moment; nothing is extrapolated past its end.

Pass predictions for coordinates you supply. The coordinates are used to evaluate a pure function and are NOT logged, stored, counted or transmitted anywhere; nothing is inferred, geolocated or defaulted, and omitting them returns an error rather than a guess. Each pass states whether it is actually visible — sunlit station, dark sky — or which of those conditions failed. No weather is modelled. Note that the website itself does not call this endpoint: the pass page ships orbital data to the browser and computes there, so a reader's coordinates never leave their device at all.

A year of dated astronomical events, each carrying the provenance of its date. `basis` is one of `computed` (derived here, with `method` naming the algorithm and version), `source-backed` (published by an authority, with `source` naming it), `forecast` (an annual recurrence, approximate to about a day) or `planned` (somebody's intention, with `source.lastVerifiedAt` giving the time it was last confirmed). `precision` says how much of the timestamp means anything — a launch scheduled to the quarter is not a timestamp to the minute — and `confirmed` is false for everything that can still move. Categories whose provider could not be reached are reported in `gaps` rather than silently omitted.

Every solar and lunar eclipse of the twenty-first century, reproduced from NASA/GSFC's Five Millennium Catalog by Espenak and Meeus. The catalogue's instants are Terrestrial Dynamical Time; `greatestEclipseUtc` is that time less the catalogue's own `deltaTSeconds`, and both are returned so the arithmetic can be checked rather than trusted. These are the circumstances of GREATEST eclipse only — not local circumstances, which need the Besselian elements NASA publishes separately.

The upcoming orbital launch schedule from Launch Library 2, maintained by The Space Devs — a community aggregation of operator and agency announcements, NOT a schedule published by any space agency. Every date is a No Earlier Than value that moves, often by weeks. `netPrecision` is the provider's own statement of how precisely the date is known, from the second down to the year, and `lastUpdated` is when the provider last confirmed the entry; both are passed through unchanged because without them a launch date cannot be used honestly.

A SPARQL 1.1 query endpoint over the graph's RDF. Architecture-ready: the JSON-LD/RDF export is live at /data/graph.jsonld and loads into any triple store today; a hosted SPARQL service is not yet available. No live endpoint is advertised.

A GraphQL endpoint over the same typed graph. Architecture-ready: the schema maps onto the graph and the REST API delivers the same data today; the resolver layer is not yet served.

Planned (v1, future). Would accept a structured proposal for review. NOT implemented: there is no write endpoint, no authentication, and no persistence in this program.

Planned. Relationship ids (from|type|to) are not URL-safe as path segments; today, filter the list endpoint by from/to/type instead.

Planned. A generic per-provider observation endpoint. The connected space-weather providers are already served by the /api/v0/live/space-weather endpoints below, which return each product in its own honesty envelope; this generic form awaits the ephemeris and orbital providers.