Coverage and scope

RoxyAPI computes deterministic systems from a birth moment, a date, or a question, and serves all of them on one key. This page is the boundary. It says which systems are served, which are not, and what to call when the answer is no.

For the catalog of what IS served, start at the Introduction or open the API reference.

Why a system may be absent

There are two reasons, and they are not interchangeable.

It is licensed. Some modern systems are copyrighted works owned by a living author or a publisher, and are licensed only through that publisher. RoxyAPI does not serve those, and does not reproduce their terminology, their naming layers, or their published text. Clean commercial licensing is something every customer gets in writing, so it has to hold in both directions.

It is not built. Some traditional systems carry no licensing question and are simply not in the catalog today. Chakra systems and runes sit here. Absence is a catalog fact and nothing more.

Gene Keys

RoxyAPI does not serve Gene Keys.

Gene Keys is a copyrighted body of work by Richard Rudd, published by Gene Keys Publishing Ltd, and the name is a registered trademark. The published terms allow commercial use of the material only under a formal licence, and the licences on offer cover teaching and referral rather than redistribution through software. No RoxyAPI endpoint returns a hologenetic profile, the Shadow, Gift and Siddhi naming, the spheres, or the sequences.

What is computable is the layer underneath, and RoxyAPI already returns it in full.

The hexagram layer underneath

Gene Keys, Human Design and the I Ching all read the same 64 hexagram wheel. A profile in any of them is built from two moments, the birth itself and a design moment on the 88 degree solar arc before it, and every activation lands on a numbered hexagram and one of its six lines. The numbering is shared: key 61 is gate 61 is hexagram 61.

RoxyAPI computes that layer with Roxy Ephemeris, verified against NASA JPL Horizons.

curl -X POST https://roxyapi.com/api/v2/human-design/bodygraph \
  -H "X-API-Key: $ROXY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"date":"1990-01-15","time":"14:30","timezone":"Asia/Kolkata"}'

Every entry in gates carries the planet, the chart side, the gate, the line, and the matching hexagram:

{
  "planet": "Sun",
  "side": "personality",
  "gate": 61,
  "line": 5,
  "gateName": "Mystery",
  "ichingHexagram": { "number": 61, "english": "Inner Truth" }
}

GET /iching/hexagrams/61 then returns that hexagram as a full reading: the Chinese name, both trigrams, the judgment, the image, and all six changing lines. Together the two calls give you the numbered skeleton a reader is looking at, carrying traditional I Ching meaning rather than a licensed naming layer.

Dreamspell and the 13 Moon calendar

RoxyAPI serves the classical Maya day count only.

This is not an absence in either sense above. The Mesoamerican domain is built and served: the Tzolkin day signs, the Haab year, the Calendar Round and the five position Long Count, computed as the unbroken count that runs from the Long Count epoch, under a correlation constant you name and that comes back on every response. What is not served is a second, different count that shares the vocabulary.

Dreamspell, also published as the 13 Moon calendar, is a modern system. It freezes its count on 29 February, so it has drifted away from the classical day count by a different amount at every date, and where the two agree they agree by coincidence. No RoxyAPI endpoint returns a Dreamspell kin number, a galactic signature, a tone, or a 13 Moon date.

The classical answer is one call:

curl -X POST https://roxyapi.com/api/v2/mesoamerican-astrology/mayan/chart \
  -H "X-API-Key: $ROXY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"date":"2012-12-21"}'

Every response names the convention it was computed under:

{
  "calendarRound": "4 Ajaw 3 Kʼankʼin",
  "longCount": { "formatted": "13.0.0.0.0", "daysSinceEpoch": 1872000 },
  "conventions": { "correlation": "gmt-584283", "yearBearerSystem": "classic" }
}

conventions is what to show a user who says another site disagrees. It names the correlation constant the answer was computed under, so a disagreement between two classical calculators is diagnosable in one line rather than mysterious. Full request and response shapes are in the Mayan astrology guide.

No prakriti questionnaire

RoxyAPI serves the Ayurveda that is computed, and nothing that asks a user about their own body.

This is not an absence in either sense above. The Ayurveda API is built and served: the vata, pitta and kapha constitution read from a verified sidereal birth chart, the dinacharya day computed from the real sunrise at a place, the ritucharya season resolved from real solar ingress instants, and the catalogue of doshas, tastes and qualities from the primary texts, every value carrying the work, the chapter and the verse behind it.

What is not served is the other half of what a consumer dosha site usually ships. There is no questionnaire that infers a constitution from answers about a body or a set of habits, no balancing route, no field that names a substance, and no input anywhere for a health complaint. No endpoint accepts one, and none sits behind a flag.

That boundary is the useful part rather than a gap, and it pays in two directions. A questionnaire answer is personal information about a body; a birth date, a time and a place is the same input a natal chart already takes, so a product can hold the whole domain in the same store, the same cache and the same prompt as the rest of its astrology. And a chart is reproducible: the same birth data gives the same reading in five years, while a quiz gives a different answer on a different afternoon.

So the constitution call takes birth data and nothing else:

curl -X POST https://roxyapi.com/api/v2/ayurveda/constitution \
  -H "X-API-Key: $ROXY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"date":"1990-07-04","time":"10:12:00","latitude":28.6139,"longitude":77.209,"timezone":5.5}'

Every Ayurveda response also carries a meta.disclaimer string in the language it was requested in, stating that the reading is for general wellness and cultural interest rather than medical advice. Render it. Full request and response shapes are in the Ayurveda guide.

Frequently asked questions