> Documentation index: https://roxyapi.com/llms.txt. Building an integration? Read https://roxyapi.com/AGENTS.md first.

# Astrology API 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](/docs/introduction) or open the [API reference](/api-reference).

## Why a system may be absent

There are three 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.

**It has no defining rule.** Some modern readings have no published method that practitioners agree on, so any answer would be one invented rule presented as a calculation. Every value RoxyAPI serves is checked against a named authority, and a reading with no authority cannot be. Starseed origins sit here.

## 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, its own engine reading the NASA JPL DE440 ephemeris directly, verified against NASA JPL Horizons.

```bash
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:

```json
{
  "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:

```bash
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:

```json
{
  "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](/docs/guides/mesoamerican-astrology).

## 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](/docs/guides/ayurveda) 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:

```bash
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](/docs/guides/ayurveda).

## Starseed origins

**RoxyAPI does not assign a starseed type.**

A starseed reading, also written star seed, maps a birth chart to a star system of origin, such as the Pleiades, Sirius, Arcturus, Lyra, Orion or Andromeda. Readers do not share one rule for it. The most common method looks for the fixed stars of a star family within a degree or two of the Sun, Moon, Ascendant, Midheaven or North Node. Other readers count sign degrees, repeated digits and house placements that involve no star at all. Even readers of the fixed star method differ on which star stands for which family, which chart points count, how wide the orb is, and which origin wins when several stars are contacted. A single type returned by an API would be one of those rules dressed as a fact.

What is computable is the layer the fixed star method reads: where the fixed stars sit in a birth chart and which planets, nodes and angles they touch. RoxyAPI returns that in full, for a catalog that includes Alcyone in the Pleiades, Sirius, Arcturus, Vega in Lyra, Rigel, Betelgeuse and Bellatrix in Orion, Alpheratz in Andromeda, and Toliman and Hadar in Centaurus.

```bash
curl -X POST "https://roxyapi.com/api/v2/astrology/fixed-stars?orb=3" \
  -H "X-API-Key: $ROXY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"date":"1990-07-15","time":"14:30:00","latitude":40.7128,"longitude":-74.006,"timezone":"America/New_York"}'
```

Every star comes back with its position, sign, magnitude and traditional nature, and `conjunctions` lists each contact with a planet, a lunar node, the Ascendant or the Midheaven, tightest first:

```json
{
  "star": "Vega",
  "point": "Neptune",
  "orb": 2.2853
}
```

The starseed reading itself is your interpretation layer. For the fixed star method, pick the stars, chart points and orb your tradition uses and read them from `stars` and `conjunctions`. A degree or house method reads the same chart from `POST /astrology/natal-chart` instead. Either way the rule is yours, stated in your product and written in your own voice, as described in [own your interpretation layer](/docs/guides/calculation-engine). Full request and response shapes are in the [API reference](/api-reference#tag/western-astrology/POST/astrology/fixed-stars).

## Frequently asked questions


### Does RoxyAPI have Gene Keys?
No. Gene Keys is a copyrighted work published by Gene Keys Publishing Ltd and its name is a registered trademark. Commercial use of the material requires a formal licence from the publisher, and the licences on offer cover teaching and referral rather than redistribution through software, so no RoxyAPI endpoint returns a Gene Keys profile or any of its naming.

### Can I build a Gene Keys style profile from RoxyAPI data?
RoxyAPI gives you the calculated layer: the gate, the line and the hexagram for every planetary activation on both the personality and design sides, from `POST /human-design/bodygraph`. Any naming layer you place on top is yours to license. If that layer is Gene Keys material, license it from the publisher.

### Why do the gate and line in my chart match my Gene Keys profile?
Because it is the same calculation. Both read the 64 hexagram wheel from the same two moments, the birth and the design point on the 88 degree solar arc, so the numbers agree by construction. What differs is the interpretation laid over them.

### Why does my Mayan sign here differ from a 13 Moon or Dreamspell app?
Because they are two different counts. RoxyAPI runs the classical Maya day count, the unbroken count from the Long Count epoch, and names the correlation constant it used under `conventions` on every response. Dreamspell and the 13 Moon calendar freeze their count on 29 February, so they have drifted away from the classical count by a different amount at every date. Neither is a miscalculation of the other, and a sign computed here is the one a daykeeper reading the classical count would give.

### Does RoxyAPI calculate my starseed type?
No. Readers do not agree on one method for mapping a birth chart to a star system of origin, so RoxyAPI does not return a starseed type. It does return what the most common method reads: the fixed star positions for the Pleiades, Sirius, Arcturus, Vega, Orion and Andromeda, and their conjunctions to your planets, lunar nodes and angles, from `POST /astrology/fixed-stars`.

### What other systems does RoxyAPI not cover?
Traditional systems that are simply not built include chakra systems and runes, and none of those carries a licensing question. Separately, any modern system whose text and terminology are owned and licensed by a publisher is out of scope for the same reason Gene Keys is.

### Does RoxyAPI reproduce copyrighted interpretation text from any system?
No. Every interpretation served is written for RoxyAPI and checked against named authorities for correctness. Nothing is lifted or paraphrased out of a licensed body of work, which is what keeps the commercial licence attached to your API key clean. The method is published on the [methodology](/methodology) page.

### What if I need a system you do not cover?
Ask. Coverage follows what customers actually ship, and a real use case moves a domain up the list faster than anything else. [Contact us](/contact) with the system and what you are building.