01
559 documented API endpoints
One coherent platform catalogue: 559 REST endpoints across 26 tagged categories, counted from the spec served at /.well-known/openapi.json rather than from a marketing figure.
Roadmap / source snapshot, July 2026
It separates what the published spec contains from active work and open exploration. Presence is not availability.
In current source
In specCounted from the published spec, not asserted. Presence in the spec is not blanket production evidence: availability, service commitments, packages, language coverage, report readiness and latency remain plan-, family- and endpoint-specific until contract and live verification.
Calculation surface
01
One coherent platform catalogue: 559 REST endpoints across 26 tagged categories, counted from the spec served at /.well-known/openapi.json rather than from a marketing figure.
02
Of the 26 tagged categories in the spec, 16 name a spiritual or divinatory system: Vedic, Western, KP, Tarot, Chinese, Human Design, I Ching, Palmistry, Runes, Lenormand, Angel Numbers and others. The remainder are delivery surfaces and plumbing, and are not counted as domains. Per-system availability and isolation require contract plus live endpoint verification.
03
The spec exposes divisional and ashtakavarga endpoints spanning Rasi (D1) through Shashtiamsa (D60). D1 to D60 is a range, not 60 separate charts, and the set of supported divisors is a request parameter rather than an endpoint count, so it is not stated here as a figure. Calculation availability requires endpoint verification.
04
The source catalogue references multiple dasha systems, dosha analysis, Panchang elements and Muhurta timing. Route-by-route inputs, calculation coverage and availability require endpoint verification.
05
The source catalogue references Tarot, numerology, Chinese astrology, Human Design, I Ching, matrimony matching and additional divination surfaces. Availability and response contracts require endpoint verification.
Engines and interfaces
06
Current source identifies an in-house astronomical engine under Apache-2.0 and a reproducible JPL DE440 benchmark with results by celestial body. Package, version and benchmark-artifact availability should be verified before production use.
07
Current source describes a natural-language query surface constrained by computed chart data and source-grounding controls for curriculum texts such as BPHS, Phaladeepika, Saravali and Jaimini. Generated interpretation remains probabilistic and requires endpoint verification.
08
The retained source describes a speech-to-interpretation surface for conversational integrations. Supported input and output languages, plan access and runtime availability require endpoint-level verification.
09
The retained catalogue describes an MCP package spanning charts, dashas, panchang and interpretation. No tool manifest ships in this repository, so no tool count is claimed. Package publication, version compatibility and callable runtime coverage require package and live-tool verification.
10
Current source references JavaScript and Python SDKs plus a WordPress plugin. Registry publication, supported versions, package integrity and compatibility must be checked in the applicable distribution channel before integration.
Delivery and output
11
The catalogue describes mock endpoints intended to follow documented response shapes. The published spec contains no mock endpoints to count, and the only sandbox figure in the repo is stated against a different endpoint total, so no count is claimed here. Keyless access, coverage and production-shape parity require live sandbox readback; the sandbox is not a free production tier.
12
The API accepts 30 values for the language parameter: English, 15 Indic and 14 international, compiled into the service itself. The two frontend catalogues in this repository now list the same 30 and are asserted against the API list on every build. An accepted language does not prove fully localized output, which requires report-family validation.
13
The report catalogue lists 480 planned types, of which its own metadata marks 119 live. The live figure is the one quoted, because it is the one a customer can buy. Each family must separately pass render, input-contract, computed-versus-generated, Rule-22 citation-provenance, language-localization and white-label verification.
Every tagged category in the published spec: 559 endpoints across 26 categories, counted from the same openapi.json a client fetches. Presence in the spec is not a service commitment; availability and limits remain plan- and contract-specific.
Share of the 559 published endpoints
Divinatory and astrological systems. These are the 16 counted as domains.
| Category | Endpoints |
|---|---|
| Vedic Astrology | 235 |
| Western Astrology | 58 |
| Tarot | 26 |
| Chinese Astrology | 15 |
| Matchmaking | 14 |
| Crystals | 10 |
| Human Design | 10 |
| Spirituality | 10 |
| iching | 8 |
| Biorhythm | 6 |
| Dreams | 6 |
| Angel Numbers | 5 |
| Lenormand | 5 |
| Palmistry | 5 |
| Runes | 5 |
| Oracle | 4 |
How a reading is asked for and returned, rather than a system of its own.
| Category | Endpoints |
|---|---|
| AI Query | 62 |
| Calendar | 23 |
| Daily Horoscope | 12 |
| Voice | 4 |
Reading topics and platform utilities. Counted as endpoints, not as domains.
| Category | Endpoints |
|---|---|
| Health | 8 |
| Lifestyle | 8 |
| Career & Finance | 7 |
| Calculators | 5 |
| Widgets | 5 |
| Geocode | 3 |
All three groups share one linear axis, 0 to 235 endpoints, so a bar means the same length in every group. 26 categories, 559 endpoints, counted from openapi.json.
Astronomical inputs are calculated separately from generated narrative. Availability commitments and support levels vary by subscription plan, and latency varies by endpoint, request depth, load and response length. Current source references JPL DE440 benchmark results by celestial body; verify the artifact before relying on it. It also references NVIDIA Inception and Google for Startups; current participation requires external verification.
These are source-authored progress estimates, not production evidence, release dates or delivery commitments. They require current owner and acceptance verification.
119 of 480 planned report types are live, and family readiness is not uniform. Expansion must preserve separate render and input acceptance, computed-versus-generated disclosure, Rule-22 citation provenance, language localization and white-label verification for every family.
Source estimate, not acceptanceCurrent source marks deeper theming, custom personas, tenant-level controls, branded domains and response presentation as active enterprise work. Scope and readiness require owner and acceptance verification.
Source estimate, not acceptanceCurrent source marks event-driven hooks for transits, dasha changes, daily panchang and report completion as active work. Event coverage, delivery semantics and readiness require contract and acceptance verification.
Source estimate, not acceptanceIn exploration
An honest look at the long horizon. The 12 themes below contain 108 exploration entries: aspirational directions, not committed dates. They show the size of the ambition without presenting exploration as shipped scope.
Exploration How to read this section. Everything here is exploratory, not a delivery promise. Items may move into planned or active source status, but production availability is only established by applicable contract, acceptance evidence and live readback.
9 items
9 items
9 items
9 items
9 items
9 items
9 items
9 items
9 items
9 items
9 items
9 items
The published spec carries 559 endpoints today. Review the public contract, current availability and the appropriate plan before a production rollout.