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

# Astrology API cheatsheet for AI agents

One-line semantics for the most-reached-for endpoints, grouped by API domain. Read this first when an agent needs a starting point. Full request and response schemas live in the OpenAPI spec at `https://roxyapi.com/api/v2/openapi.json`; query it with the jq recipe in [AGENTS.md](/AGENTS.md).

## Astrology

- `POST /astrology/natal-chart`: Western birth chart with planets, houses, aspects, ascendant, midheaven.
- `GET /astrology/horoscope/{sign}/daily`: Daily horoscope. Also `/weekly` and `/monthly` variants.
- `POST /astrology/synastry`: Inter-chart aspect analysis between two people.
- `POST /astrology/compatibility-score`: Percent plus category breakdowns and archetype.
- `POST /astrology/transits`: Current sky. Pass optional `natalChart` for personalized aspects.
- `GET /astrology/moon-phase/current`: Current moon phase, illumination, sign.

### TypeScript SDK example

```typescript
roxy.astrology.generateNatalChart({ body: { date: '1990-06-15', time: '14:30:00', latitude: 40.7128, longitude: -74.006, timezone: 'America/New_York' } })
```

### Python SDK example

```python
roxy.astrology.generate_natal_chart(date="1990-06-15", time="14:30:00", latitude=40.7128, longitude=-74.006, timezone="America/New_York")
```

### PHP SDK example

```php
$roxy->astrology->generateNatalChart(date: '1990-06-15', time: '14:30:00', latitude: 40.7128, longitude: -74.006, timezone: 'America/New_York')
```

### C# SDK example

```csharp
roxy.Astrology.NatalChart.PostAsync(new() { Date = new Date(1990, 6, 15), Time = new Time(14, 30, 0), Latitude = 40.7128, Longitude = -74.006, Timezone = new() { String = "America/New_York" } })
```

## Vedic

- `POST /vedic-astrology/birth-chart`: Kundli with twelve rashi houses, planet placements, interpretations.
- `POST /vedic-astrology/panchang/detailed`: Daily panchang with rahu kaal, muhurtas, gulika, chandrabalam, tarabalam.
- `POST /vedic-astrology/panchang/basic`: Tithi, nakshatra, yoga, karana.
- `POST /vedic-astrology/panchang/choghadiya`: Eight day and eight night electional periods.
- `POST /vedic-astrology/dasha/current`: Current Mahadasha, Antardasha, Pratyantardasha, Sookshma.
- `POST /vedic-astrology/dasha/major`: Full 120-year Vimshottari timeline.
- `POST /vedic-astrology/dosha/manglik`: Mangal Dosha check.
- `POST /vedic-astrology/dosha/kalsarpa`: Kaal Sarp Dosha check.
- `POST /vedic-astrology/dosha/sadhesati`: Sade Sati (Saturn transit) check.
- `POST /vedic-astrology/compatibility`: Guna Milan (36-point Ashtakoota matching).
- `POST /vedic-astrology/compatibility/dashakoot`: South Indian ten porutham match. `person1` is the GROOM and `person2` the BRIDE, and five of the ten count from the bride, so the order matters. Returns `total` out of 10 plus `rajju` and `vedha` as hard vetoes that set `verdict` to `rejected` at any total.
- `POST /vedic-astrology/compatibility/papasamyam`: malefic balance between the two charts, counted from the Lagna, the Moon and Venus. Returns both totals with the graha and bhava behind every point. `balanced` means the bride carries no more than the groom.
- `POST /vedic-astrology/navamsa`: D9 chart.
- `POST /vedic-astrology/kp/chart`: KP chart with cusps, planets, sub-lords.
- `POST /vedic-astrology/kp/planets`: KP planets with sub-lord and sub-sub-lord.
- `POST /vedic-astrology/kp/ruling-planets`: KP ruling planets for horary.
- `GET /vedic-astrology/nakshatras/{id}`: Single nakshatra detail (e.g. `ashwini`, `pushya`).

### TypeScript SDK example

```typescript
roxy.vedicAstrology.generateBirthChart({ body: { date: '1990-06-15', time: '14:30:00', latitude: 51.5074, longitude: -0.1278, timezone: 'Europe/London' } })
```

### Python SDK example

```python
roxy.vedic_astrology.generate_birth_chart(date="1990-06-15", time="14:30:00", latitude=51.5074, longitude=-0.1278, timezone="Europe/London")
```

### PHP SDK example

```php
$roxy->vedicAstrology->generateBirthChart(date: '1990-06-15', time: '14:30:00', latitude: 51.5074, longitude: -0.1278, timezone: 'Europe/London')
```

### C# SDK example

```csharp
roxy.VedicAstrology.BirthChart.PostAsync(new() { Date = new Date(1990, 6, 15), Time = new Time(14, 30, 0), Latitude = 51.5074, Longitude = -0.1278, Timezone = new() { String = "Europe/London" } })
```

## Forecast

Cross-domain timing in one stateless call. Body wraps `birthData` (`date`, `time`, `timezone`; `latitude`/`longitude` optional, default 0), plus optional `startDate`, `endDate` (clamped to a 90-day horizon), and `minSignificance`. Event `type` and `domain` are stable English codes; only `description` localizes with `?lang=`.

- `POST /forecast/transits`: Western transit-to-natal aspects, sign ingresses, and retrograde stations over the window.
- `POST /forecast/timeline`: Cross-domain merge: Western transits plus Vedic Vimshottari dasha boundaries plus biorhythm critical days, significance-scored and time-ordered. Optional `domains` subset.
- `POST /forecast/solar-return`: Annual solar-return chart cast on the Sun's return to its natal longitude (birthday / year-ahead). Needs coordinates: body is `date`, `time`, `year`, `latitude`, `longitude`, `timezone`, so call `/location/search` first.
- `POST /forecast/significant-dates`: High-significance highlights only (`minSignificance` defaults to 70).
- `POST /forecast/digest`: Ranked top-N summary of the most significant events for a date.

### TypeScript SDK example

```typescript
roxy.forecast.forecastTransits({ body: { birthData: { date: '1990-06-15', time: '14:30:00', timezone: 'America/New_York' } } })
```

### Python SDK example

```python
roxy.forecast.forecast_transits(birth_data={"date": "1990-06-15", "time": "14:30:00", "timezone": "America/New_York"})
```

### PHP SDK example

```php
$roxy->forecast->forecastTransits(birthData: ['date' => '1990-06-15', 'time' => '14:30:00', 'timezone' => 'America/New_York'])
```

### C# SDK example

```csharp
roxy.Forecast.Transits.PostAsync(new() { BirthData = new() { Date = new Date(1990, 6, 15), Time = new Time(14, 30, 0), Timezone = new() { String = "America/New_York" } } })
```

## Human Design

No coordinates needed: Human Design uses the birth instant and ecliptic longitudes, not the observer location. Body is `date`, `time`, `timezone` (no `latitude`/`longitude`, no `/location/search` step).

- `POST /human-design/bodygraph`: Full chart in one call: type, strategy, authority, profile, definition, incarnation cross, the 9 centers, defined channels, and all 26 gate activations.
- `POST /human-design/type`: Energy type (Generator, Manifesting Generator, Projector, Manifestor, Reflector) with strategy and authority. The quiz-style entry point.
- `POST /human-design/connection`: Two-person compatibility across the 36 channels (electromagnetic, dominance, compromise, companionship).
- `POST /human-design/profile`: Profile (e.g. 5/1, 6/2) with personality and design line keynotes.
- `POST /human-design/transit`: Today's planetary activations overlaid on a natal bodygraph. Body wraps `birthData`.
- `GET /human-design/gates/{number}`: Single gate reference (1-64).

### TypeScript SDK example

```typescript
roxy.humanDesign.generateBodygraph({ body: { date: '1990-06-15', time: '14:30:00', timezone: 'America/New_York' } })
```

### Python SDK example

```python
roxy.human_design.generate_bodygraph(date="1990-06-15", time="14:30:00", timezone="America/New_York")
```

### PHP SDK example

```php
$roxy->humanDesign->generateBodygraph(date: '1990-06-15', time: '14:30:00', timezone: 'America/New_York')
```

### C# SDK example

```csharp
roxy.HumanDesign.Bodygraph.PostAsync(new() { Date = new Date(1990, 6, 15), Time = new Time(14, 30, 0), Timezone = new() { String = "America/New_York" } })
```

## Chinese Astrology

No coordinates needed for the default clock. Body is `date`, `time`, `timezone`; `longitude` is required only when `hourClock` is `local-mean` or `solar`, which return 400 without it. Three school splits are typed request fields with named defaults and are echoed back on every response in `conventions`: `dayBoundary` (`split-zi` default, also `midnight`, `early-zi`), `yearBoundary` (`li-chun` default on the BaZi family, `lunar-new-year` default on `/zodiac/sign`), `hourClock` (`clock` default). Machine identifiers stay canonical English in every language; display text arrives in `*Localized` siblings.

- `POST /chinese-astrology/bazi/chart`: Four Pillars in one call: year, month, day and hour pillars with stems, branches, Ten Gods, hidden stems and Na Yin, plus `dayMaster`, `fiveElements`, `interactions` and `conventions`. The day pillar is `pillars[2]` and its `tenGod.name` is always `Day Master`.
- `POST /chinese-astrology/bazi/day-master`: Strong or weak `verdict` with a numeric `score`, the three contributing `factors`, and `favorableElements` / `unfavorableElements`.
- `POST /chinese-astrology/bazi/luck-pillars`: Ten-year decade cycles with `startAge`, `startYear`, `endYear`. Requires `gender` in the body, which sets the direction the pillars run and cannot be derived from the chart.
- `POST /chinese-astrology/bazi/annual-forecast`: One `year` against the natal chart, with `tenGod`, `yearBranchRelation` and the `benMingNian` flag.
- `POST /chinese-astrology/zodiac/sign`: Zodiac animal from a date alone. Defaults `yearBoundary` to `lunar-new-year`, unlike the BaZi family.
- `GET /chinese-astrology/zodiac/compatibility/{sign1}/{sign2}`: Pair relationship, `score` out of 100, strengths, frictions, advice. No birth time.
- `GET /chinese-astrology/calendar/day/{date}`: Tong Shu almanac day: `dayOfficer`, `mansion`, `clashAnimal`, `favours`, `avoids`.
- `POST /chinese-astrology/calendar/auspicious-days`: Date selection. Takes `activity`, `startDate`, `endDate`; the range is capped at 93 days and a wider one returns 400.
- `POST /chinese-astrology/calendar/lunar-date`: Gregorian to lunar and back, leap months handled. Computed on one world reference frame, so a lunar date does not shift with caller timezone.

### TypeScript SDK example

```typescript
roxy.chineseAstrology.generateBaziChart({ body: { date: '1990-06-15', time: '14:30:00', timezone: 'America/New_York' } })
```

### Python SDK example

```python
roxy.chinese_astrology.generate_bazi_chart(date="1990-06-15", time="14:30:00", timezone="America/New_York")
```

### PHP SDK example

```php
$roxy->chineseAstrology->generateBaziChart(date: '1990-06-15', time: '14:30:00', timezone: 'America/New_York')
```

### C# SDK example

```csharp
roxy.ChineseAstrology.Bazi.Chart.PostAsync(new() { Date = new Date(1990, 6, 15), Time = new Time(14, 30, 0), Timezone = new() { String = "America/New_York" } })
```

## Feng Shui

The lightest input in the catalog. Personal calls need a birth `date` plus `gender`, which selects the Kua formula variant, and nothing else: no birth time, no coordinates, no `/location/search` step. Building calls need a `period` (1 to 9) and a facing direction. The feng shui year turns at Li Chun in early February, so a January birthday resolves to the previous `solarYear`, which the response states along with the `boundaryDate` it used.

- `POST /feng-shui/kua`: Kua number with `rawKua`, `reassigned`, east or west `group`, the personal trigram, and all eight sectors with `star`, `nature` and `rank`. `kua` is never 5; a raw 5 becomes 2 under the `male` formula and 8 under the `female` one.
- `POST /feng-shui/eight-mansions`: Full Ba Zhai map with a composed `reading` per sector plus `bestSector` and `worstSector`. Accepts a `kua` directly or derives one from `date` and `gender`. Optional `facing` here is a capitalised compass sector such as `South`.
- `POST /feng-shui/flying-stars/natal`: Nine-palace chart for a building. Send `facingDegrees` (0 to 360, measured looking out from inside) or `facing` (one of the 24 mountains, by id such as `wu` or label such as `S2`). Sending neither returns 400.
- `GET /feng-shui/flying-stars/annual/{year}`: Annual star overlay with `centerStar`, `changeoverDate` and nine palaces.
- `GET /feng-shui/afflictions/{year}`: Tai Sui, Sui Po, San Sha and the Five Yellow. Their directional rules differ: Tai Sui should be behind you and never faced, San Sha is the reverse, and San Sha spans 75 degrees with three named `parts` rather than one direction.
- `GET /feng-shui/periods`: The 1864 to 2043 cycle plus `currentPeriod`. Read the period from here rather than hardcoding it.
- `GET /feng-shui/bagua`: Later Heaven bagua. Returns 9 sectors, not 8: the eight compass sectors plus `health` at the Center, where `direction` and `trigram` are absent rather than null.

### TypeScript SDK example

```typescript
roxy.fengShui.calculateKuaNumber({ body: { date: '1990-06-15', gender: 'female' } })
```

### Python SDK example

```python
roxy.feng_shui.calculate_kua_number(date="1990-06-15", gender="female")
```

### PHP SDK example

```php
$roxy->fengShui->calculateKuaNumber(date: '1990-06-15', gender: 'female')
```

### C# SDK example

```csharp
roxy.FengShui.Kua.PostAsync(new() { Date = new Date(1990, 6, 15), Gender = RoxyApi.FengShui.Kua.KuaPostRequestBody_gender.Female })
```

## Mesoamerican

The lightest input in the catalog alongside feng shui: every route takes a birth `date` in `YYYY-MM-DD` and nothing else, no birth time, no coordinates, no timezone, no `/location/search` step. Dates are read as proleptic Gregorian throughout, including before the 1582 reform, so a converter that switches to the Julian calendar there will differ by ten or eleven days. Three school splits are typed request fields with named defaults: `correlation` on every Maya route, `yearBearerSystem` on the chart, `directionScheme` on compatibility and the sign catalogue. Whichever was used comes back under `conventions` on every response, which is the field to echo when a user says another site disagrees.

- `POST /mesoamerican-astrology/mayan/tzolkin`: Mayan day sign from a birth date, with coefficient, trecena and a composed nawal reading. The sign arrives in three namings: `daySign` (canonical id, never translated), `daySignName`, `daySignClassic` and `daySignKiche`.
- `POST /mesoamerican-astrology/mayan/chart`: The whole day in one call. Tzolkin, Haab, the five position `longCount` with `daysSinceEpoch` and `julianDayNumber`, `calendarRound`, `lordOfNight`, `yearBearer`, the five point Cruz Maya and a `summary`.
- `POST /mesoamerican-astrology/mayan/long-count/convert`: Long Count to civil date or back. Send exactly one of `date` or `longCount`; both or neither returns 400. Pre-1582 dates come back with a `note` explaining the proleptic Gregorian reading.
- `GET /mesoamerican-astrology/mayan/daily`: Day sign of the day plus an `overview` naming the trecena. Optional `date`, cached to the UTC rollover, so a content schedule built weeks ahead matches what ships.
- `GET /mesoamerican-astrology/mayan/calendar/monthly`: Every civil day of a `year` and `month` with its day sign, number, trecena, `haab` string and `longCount`. One call fills a calendar UI.
- `POST /mesoamerican-astrology/mayan/compatibility`: Two dates in, both days plus `daysApart`, five weighted `components` with `holds`, a composite `score`, a `verdict` band and a `summary`. The score is a RoxyAPI composite with a floor of 45, so render the components rather than the number alone.
- `GET /mesoamerican-astrology/mayan/day-signs` and `/{id}`: The twenty signs. The list carries both glosses, `direction` and `color`; the single call adds the full reading and the trecena the sign opens.
- `GET /mesoamerican-astrology/mayan/trecenas` and `/{number}`: The twenty thirteen day periods, each composed from the sign it opens on.
- `GET /mesoamerican-astrology/mayan/haab-months` and `/{id}`: The nineteen Haab periods, eighteen of twenty days plus Wayebʼ of five.
- `POST /mesoamerican-astrology/aztec/tonalpohualli`: The Aztec 260 day count. Same structure as the Tzolkin under Nahuatl names and a different anchor. Takes no `correlation` field and echoes its own anchor instead.
- `GET /mesoamerican-astrology/aztec/daily`: Tonalpohualli sign of the day, same shape and same UTC rollover as the Maya daily.
- `GET /mesoamerican-astrology/aztec/day-signs` and `/{id}`, `GET /mesoamerican-astrology/aztec/trecenas` and `/{number}`: The matching Aztec catalogues.

Two response conventions worth knowing before you parse: `numberBand` is ABSENT rather than null for coefficients 4, 5, 6 and 10, because only nine of the thirteen have a character recorded, and the Aztec responses carry a `scope` sentence naming the fields that domain deliberately does not return.

### TypeScript SDK example

```typescript
roxy.mesoamericanAstrology.calculateTzolkin({ body: { date: '1990-06-15' } })
```

### Python SDK example

```python
roxy.mesoamerican_astrology.calculate_tzolkin(date="1990-06-15")
```

### PHP SDK example

```php
$roxy->mesoamericanAstrology->calculateTzolkin(date: '1990-06-15')
```

### C# SDK example

```csharp
roxy.MesoamericanAstrology.Mayan.Tzolkin.PostAsync(new() { Date = new Date(1990, 6, 15) })
```

## Vastu

Geometry in, citation out. Every route takes a plot and a facing and no birth data at all: send `plot.width` plus `plot.depth` for a compass aligned rectangle or `plot.polygon` for anything else, and either `facing` (one of the eight sectors) or `facingDegrees` (a bearing measured looking out), never both. The x axis runs east and the y axis north, and the mandala is aligned to the compass rather than to the building, so `facing` only says which side the front is on. Every verdict carries a `source` object: either a `text`, `chapter`, `verse`, `translation` and `year`, or the literal `text: "convention"` with a `basis` naming the practice, which is the discriminator to branch on. Seven school splits are typed request fields with named defaults, echoed back under `conventions` on every response: `grid`, `ayadiText`, `vyayaFormula`, `slopeSchool`, `unit`, `hastaInches` and `muhurtaText`.

- `POST /vastu/entrance`: Which of the 32 perimeter padas a main door falls on, with the `devata`, the classical `effect`, `auspiciousness` and `recommendedPadas`, the favourable padas on the same side. Send `door` coordinates or `doorPosition`, a fraction along the facing side, never both. `doorPosition` needs a cardinal facing and returns 400 on an intercardinal one.
- `POST /vastu/rooms`: A verdict per room over a closed enum of twelve types, each with `zone`, `idealDirections`, `avoidDirections`, a `remedy` and its own source. Four types carry a verse and the other eight carry convention. `score` is a RoxyAPI composite and `scoring` publishes the weights it was built from.
- `POST /vastu/plot`: `shape`, `ratio`, `slope`, `water`, `extensions`, `cuts` and `road`, each with a verdict and a source. `slopeLowDirection` is where the ground is LOW. `slope.schools` always returns BOTH the classical and the modern reading whichever `slopeSchool` you sent, with `slope.chosen` naming the one you led with.
- `POST /vastu/mandala`: The Vastu Purusha Mandala projected over the plot. 81 `cells` each with its devata and a `center` point in your coordinates, `brahmasthan` as squares plus a polygon plus an area, `marma`, the six `vamsa` diagonals and the nine `atimarma` crossings. On `grid: "64-pada"` the chapter gives structure only, so there is no devata, marma, vamsa or atimarma.
- `POST /vastu/ayadi`: The six Ayadi formulas with `multiplier`, `divisor`, `product`, `remainder` and `groupSize` shown per varga, plus `vayas` and a `verdict` whose `ayaVyaya` is one of `aya-greater`, `equal`, `aya-lesser` or `zero-remainder`. Every remainder is unit sensitive, so `unit` and `hastaInches` are inputs and never assumed.
- `POST /vastu/timing/griha-pravesh`: Every day in a window that clears the day level muhurta rules, with `admittedBy` naming the limbs that qualified it, `rules` carrying each requirement and its source, and `rejectionsByRule` counting what knocked the rest out. The window is capped at 93 days. `leftToTheAstrologer` publishes the lagna, house and owner dependent rules a date search cannot settle.
- `GET /vastu/directions`: The eight directions with `dikpala`, `kind`, the mandala `squares` and the devatas on them, and the `water` effect for that quarter.
- `GET /vastu/directions/{id}`: One of them in full, adding `element` and `places`. Ids are the sector names with case and punctuation folded, so `northeast`, `north-east` and `Northeast` all resolve.
- `GET /vastu/devatas`: The 45 devatas, paginated with `total`, `limit` and `offset`.
- `GET /vastu/devatas/{id}`: One devata with `class`, `group`, `side`, `quadrant`, `squares`, `cells`, `padaCount`, `entrancePada`, a composed `role`, the `verses` it rests on and a `note` recording a competing reading where two texts disagree.

### TypeScript SDK example

```typescript
roxy.vastu.calculateEntrancePada({ body: { plot: { width: 30, depth: 40 }, facing: 'East', doorPosition: 0.3 } })
```

### Python SDK example

```python
roxy.vastu.calculate_entrance_pada(plot={"width": 30, "depth": 40}, facing="East", door_position=0.3)
```

### PHP SDK example

```php
$roxy->vastu->calculateEntrancePada(plot: ['width' => 30, 'depth' => 40], facing: 'East', doorPosition: 0.3)
```

### C# SDK example

```csharp
roxy.Vastu.Entrance.PostAsync(new() { Plot = new() { Width = 30, Depth = 40 }, Facing = RoxyApi.Vastu.Entrance.EntrancePostRequestBody_facing.East, DoorPosition = 0.3 })
```

## Numerology

- `POST /numerology/life-path`: Pythagorean life path with master-number (11, 22, 33) and karmic-debt detection.
- `POST /numerology/chart`: Full profile: life path, expression, soul urge, personality, birth day, maturity.
- `POST /numerology/compatibility`: Couple matching by life-path / expression / soul urge. No birth time needed.
- `POST /numerology/personal-year`: Annual forecast from birthdate plus target year.
- `POST /numerology/expression`: Name-based destiny number.

### TypeScript SDK example

```typescript
roxy.numerology.calculateLifePath({ body: { year: 1990, month: 6, day: 15 } })
```

### Python SDK example

```python
roxy.numerology.calculate_life_path(year=1990, month=6, day=15)
```

### PHP SDK example

```php
$roxy->numerology->calculateLifePath(year: 1990, month: 6, day: 15)
```

### C# SDK example

```csharp
roxy.Numerology.LifePath.PostAsync(new() { Year = 1990, Month = 6, Day = 15 })
```

## Kabbalah

A string in, a number and the spelling it came from out. `POST /kabbalah/gematria` takes either `text`, a Latin name that must be written in Hebrew first, or `textHebrew`, a spelling you supply; sending both or neither returns 400. There is no standard for writing a Latin name in Hebrew, so the response returns EVERY candidate spelling in `hebrewForms` with its own values, names the one it used in `chosen`, and states the rule that chose it. Two letter maps are offered under `transliteration`: `letter-map-mathers`, the 1887 plate, writes no letter for the vowel `e` and has no Hebrew for `c`, `f`, `w` or `x`, so a name containing one of those four returns 400 naming the letters rather than dropping them; `letter-map-modern`, the modern Israeli rules, covers every Latin letter. Every form states the readings it used in `rule`. Only the birth profile needs birth data, and it takes no latitude and no longitude at all: `date`, `time` and `timezone` and nothing else. Nine school splits are typed request fields with named defaults, echoed back under `conventions` on every response that has one: `transliteration`, `misparGadol`, `atbashOutput`, `letterAttribution`, `treeVariant`, `sephirotSystem`, `angelDating`, `yearStart` and `leapDayPolicy`, plus the `afterSunset` boolean. Every cipher, letter table and path attribution carries a `tradition` and a `century`, so a Renaissance Christian cipher is never returned as rabbinic practice.

- `POST /kabbalah/gematria`: Every Hebrew spelling of the input with its cipher values and per letter breakdown, the AtBash and Albam substitutions, and the curated equal value `matches` with at least two sources each. `ciphers` filters the top level `values`; each `hebrewForms` entry keeps the full set. Top level rows carry a `name`, the catalogue display name for that `id` in the requested language, so a row labels itself without a second call. `latinCiphers: true` adds three Latin alphabet ciphers with a `lineage` sentence naming the authors, valid only with a Latin `text`.
- `GET /kabbalah/ciphers`: The provenance catalogue, 16 rows across `ciphers`, `latinCiphers` and `transformations`, each with a `definition`, `tradition`, `century`, `computed` flag and `sources`. `mispar-mispari` is the one row with `computed: false`, and this catalogue is the only place it appears: the scored arrays leave it out rather than sending it without a number.
- `POST /kabbalah/name-profile`: A name across four named readings as an OBJECT, `values.standard`, `large`, `small` and `preceding`, plus `letters` and the `sephirah` the reduced value points at. Use this for a name card and the gematria route when a reader wants every cipher.
- `POST /kabbalah/birth-profile`: `hebrewDate` with the Hebrew string and the `afterSunset` echo, `hebrewBirthday` (null with a note when that Hebrew day is missing from the target year), `angels`, always three entries with roles `body`, `character` and `spirit`, and the birth `sephirah`. `time` defaults to noon and the response says so.
- `GET /kabbalah/names`: The 72 names, paginated with `total`, `limit` and `offset`. Pass `longitude` instead and it returns the single name governing that five degree arc of the ecliptic.
- `GET /kabbalah/names/{number}`: One name by index 1 to 72, because the Latin spellings differ between published tables while the index never does. `letters` normalizes word final forms and `lettersAsWritten` keeps them, and `publishedDisagreement` appears on the one row where a second published list differs.
- `GET /kabbalah/tree`: Eleven `sephirot` rows, the 22 `paths`, the four `worlds` and the ten step `lightningFlash`. Daat is the eleventh row and carries `number: null` and no path, so filter on `number` when drawing the ten. Each world publishes BOTH readings as `sephirot` and `sephirotAlternate`.
- `GET /kabbalah/sephirot/{id}`: One sphere with `pillar`, `pillarName`, `world`, `attribution` and every path that touches it. Ids are the ten plus `daat`.
- `GET /kabbalah/letters`: All 22 letters with `total`, `classCounts` (3 mother, 7 double, 12 simple) and the `letterAttribution` in force. No pagination. Each letter carries `attribution.kind` of `element`, `planet` or `sign`, the tarot `trump` and its `path` number.
- `GET /kabbalah/letters/{id}`: One letter in full, adding `final` and `finalValue` for the five that take a word final form, and `classReading` for its class.
- `POST /kabbalah/compatibility`: Two names, `sharedValues`, a `score` and a `band`, and four weighted `components` each with `points`, `maximum` and `matched`. The score is a RoxyAPI composite, so render the components rather than the number alone. Send `firstNameHebrew` and `secondNameHebrew` to score exact spellings.
- `GET /kabbalah/daily`: The Omer day, its `weekSephirah` and `daySephirah` pairing and the printed `hebrewLabel`. The count runs forty nine days a year, so branch on `inOmer` first: outside the window the response carries `nextStart` and no reading.

Two response conventions worth knowing before you parse: every scored cipher row carries a number, because the one catalogued cipher that is not computed is omitted from `values` and `hebrewForms[].values` rather than sent with an empty one; and a cipher can be multi valued, so `otiyot-be-milui` carries `alternateValues` beside `value`. Hebrew strings are data and never translate, while `meaning`, `note`, `reading`, `rule`, `classReading`, `window`, `definition` and the letter `name` on a breakdown row do.

### TypeScript SDK example

```typescript
roxy.kabbalah.calculateGematria({ body: { text: 'Ruth' } })
```

### Python SDK example

```python
roxy.kabbalah.calculate_gematria(text="Ruth")
```

### PHP SDK example

```php
$roxy->kabbalah->calculateGematria(text: 'Ruth')
```

### C# SDK example

```csharp
roxy.Kabbalah.Gematria.PostAsync(new() { Text = "Ruth" })
```

## Tarot

- `POST /tarot/daily`: Seeded daily card.
- `POST /tarot/draw`: Custom draw of N cards (1-78).
- `POST /tarot/spreads/three-card`: Past / present / future.
- `POST /tarot/spreads/celtic-cross`: Ten-position spread.
- `POST /tarot/yes-no`: One-question, one-card reading.
- `POST /tarot/spreads/love`: Five-position relationship spread.
- `GET /tarot/cards`: 78-card catalog.
- `GET /tarot/cards/{id}`: Card detail with upright, reversed, and life-area meanings.

### TypeScript SDK example

```typescript
roxy.tarot.drawCards({ body: { count: 3 } })
```

### Python SDK example

```python
roxy.tarot.draw_cards(count=3)
```

### PHP SDK example

```php
$roxy->tarot->drawCards(count: 3)
```

### C# SDK example

```csharp
roxy.Tarot.Draw.PostAsync(new() { Count = 3 })
```

## Biorhythm

- `POST /biorhythm/daily`: Seeded daily biorhythm reading.
- `POST /biorhythm/forecast`: Multi-day range (30 to 90 days) with best, worst, and critical days.
- `POST /biorhythm/compatibility`: Cycle alignment between two people.
- `POST /biorhythm/critical-days`: Zero-crossing days in a 90 to 180 day window.

### TypeScript SDK example

```typescript
roxy.biorhythm.getReading({ body: { birthDate: '1990-06-15', targetDate: '2026-06-15' } })
```

### Python SDK example

```python
roxy.biorhythm.get_reading(birth_date="1990-06-15", target_date="2026-06-15")
```

### PHP SDK example

```php
$roxy->biorhythm->getReading(birthDate: '1990-06-15', targetDate: '2026-06-15')
```

### C# SDK example

```csharp
roxy.Biorhythm.Reading.PostAsync(new() { BirthDate = new Date(1990, 6, 15), TargetDate = new Date(2026, 6, 15) })
```

## Ayurveda

Birth data, a date and a place in; a cited reading out. Nothing here asks a user about their own body: there is no questionnaire, no balancing route, no field naming a substance and no input for a health complaint. Every value carries a `source` object naming the `text`, `chapter` and `verse` behind it, with `translation`, `year` and a `publicDomain` flag, and every response carries `meta.disclaimer`, a scope sentence in the requested language that says the reading is for general wellness and cultural interest rather than medical advice. Render it. Five school splits are typed request fields with named defaults, echoed back under `conventions`: `signDoshaScheme` on the constitution, `doshaClock` on the dinacharya, and `ritucharyaScheme`, `rituZodiac` and `hemisphere` on the ritucharya. Sanskrit identifiers (`vata`, `vasanta`, `madhura`, `guru`) never translate; the gloss beside them does.

- `POST /ayurveda/constitution`: The vata, pitta and kapha shares from a birth chart. `factors` is exactly three, the rising sign, the sign the Moon occupies and the strongest graha by shadbala, each with its own `doshas`, `weight` and `source`. `composite` carries `dominant`, `secondary`, `type` and `convention: "roxyapi/v1"` with its `weighting` published inside the response, because the texts give the factors and never the weighting. `strengthRanking` and the seven row `planetDoshas` table come back beside it. Takes `date`, `time`, `latitude`, `longitude`, optional `timezone`, `ayanamsa` and `signDoshaScheme`.
- `POST /ayurveda/dinacharya`: `sunrise`, `sunset`, `nextSunrise`, the `brahmaMuhurta` window with the `muhurtaMinutes` and `muhurtasPerAhoratra` it was built from, the six `doshaPeriods` and the `routine` as ordered items with a `timing` sentence each. Both clocks always come back: `doshaPeriods` is whichever `doshaClock` you sent and `alternatePeriods` is the other, so a product can show one and reconcile against the other. Takes `date`, `latitude`, `longitude`, optional `timezone` and `doshaClock`.
- `POST /ayurveda/ritucharya`: The season for a date with its real `start` and `end` ingress instants and the `solarMonths` it spans, plus `ayana`, `phase` with the tastes that grow in it, `strength`, `tasteIncreasing`, the nine slot `doshaCycle` and the `regimen` items. Takes `date` only, plus optional `ritucharyaScheme`, `rituZodiac` and `hemisphere`.
- `GET /ayurveda/daily`: The day composed for one place under the defaults, a lighter shape than the two POSTs combined: `brahmaMuhurta`, `doshaPeriods`, the `ritu` flattened to its ids, and a one line `summary`. Optional `date`, `latitude`, `longitude` and `timezone`, cached to the UTC rollover.
- `GET /ayurveda/doshas`: The three, each with `sanskritName`, `devanagari`, `alsoCalled`, the single `element` the verses give beside the `modernElementPair` in circulation, `qualities`, `qualityGunas` joining across to the guna table, `seats` with a `specialSeat` and a `seatsVariant` recording where a second text differs, `functions`, `states` and the five `subDoshas`.
- `GET /ayurveda/doshas/{id}`: One of `vata`, `pitta` or `kapha`. Any other id returns 400 naming the three.
- `GET /ayurveda/tastes`: The six rasas in the order the verse names them, which is also `strengthOrder` and is not the order most modern lists print. Each carries `elements`, `decreases` and `increases`, and `matrix` is the same eighteen cells inverted, keyed by dosha with `decreasedBy` and `increasedBy`.
- `GET /ayurveda/qualities`: The twenty gunas as ten opposed `pairs`, each member with its `english`, its `action` and `actionSanskrit`, and the `doshas` it belongs to. `rule` is the like-increases-like sentence the whole domain runs on.

Two response conventions worth knowing before you parse. Pagination is nominal on the three catalogue routes, since the collections are three, six and ten rows, so `limit` is capped at the collection size and `offset` is there for shape rather than for paging. And a recorded disagreement between two texts is always served rather than resolved, as a `note` inside a `source` or as a named field like `seatsVariant`, so a UI can show both readings instead of picking one silently.

### TypeScript SDK example

```typescript
roxy.ayurveda.calculateAyurvedicConstitution({ body: { date: '1990-07-04', time: '10:12:00', latitude: 28.6139, longitude: 77.209, timezone: 'Asia/Kolkata' } })
```

### Python SDK example

```python
roxy.ayurveda.calculate_ayurvedic_constitution(date="1990-07-04", time="10:12:00", latitude=28.6139, longitude=77.209, timezone="Asia/Kolkata")
```

### PHP SDK example

```php
$roxy->ayurveda->calculateAyurvedicConstitution(date: '1990-07-04', time: '10:12:00', latitude: 28.6139, longitude: 77.209, timezone: 'Asia/Kolkata')
```

### C# SDK example

```csharp
roxy.Ayurveda.Constitution.PostAsync(new() { Date = new Date(1990, 7, 4), Time = new Time(10, 12, 0), Latitude = 28.6139, Longitude = 77.209, Timezone = new() { String = "Asia/Kolkata" } })
```

## I-Ching

- `POST /iching/daily`: Seeded daily hexagram.
- `POST /iching/daily/cast`: Seeded three-coin daily variant.
- `GET /iching/cast`: Random three-coin cast (optional `seed` for determinism).
- `GET /iching/hexagrams/{number}`: Hexagram 1 to 64 detail.

### TypeScript SDK example

```typescript
roxy.iching.castReading({})
```

### Python SDK example

```python
roxy.iching.cast_reading()
```

### PHP SDK example

```php
$roxy->iching->castReading()
```

### C# SDK example

```csharp
roxy.Iching.Cast.GetAsync()
```

## Crystals

- `GET /crystals/zodiac/{sign}`: Crystals paired with a zodiac sign.
- `GET /crystals/chakra/{chakra}`: Chakra stones. Path is case-insensitive, space-separated: `Heart`, `Root`, `Sacral`, `Solar Plexus` (URL-encoded `Solar%20Plexus`), `Throat`, `Third Eye` (`Third%20Eye`), `Crown`.
- `GET /crystals/birthstone/{month}`: Birthstones by month (1 to 12).
- `GET /crystals/search?q=`: Free-text crystal search.

### TypeScript SDK example

```typescript
roxy.crystals.getCrystalsByZodiac({ path: { sign: 'aries' } })
```

### Python SDK example

```python
roxy.crystals.get_crystals_by_zodiac(sign="aries")
```

### PHP SDK example

```php
$roxy->crystals->getCrystalsByZodiac(sign: 'aries')
```

### C# SDK example

```csharp
roxy.Crystals.Zodiac["aries"].GetAsync()
```

## Dreams

- `GET /dreams/symbols/{id}`: Dream symbol detail (e.g. `flying`, `losing-teeth`).
- `GET /dreams/symbols`: Browse catalog.
- `POST /dreams/daily`: Daily dream symbol prompt.

### TypeScript SDK example

```typescript
roxy.dreams.getDreamSymbol({ path: { id: 'flying' } })
```

### Python SDK example

```python
roxy.dreams.get_dream_symbol(id="flying")
```

### PHP SDK example

```php
$roxy->dreams->getDreamSymbol(id: 'flying')
```

### C# SDK example

```csharp
roxy.Dreams.Symbols["flying"].GetAsync()
```

## Angel Numbers

- `GET /angel-numbers/numbers/{number}`: Canonical number meaning (string param, e.g. `1111`, `777`).
- `GET /angel-numbers/lookup?number=`: Universal lookup for any positive integer with digit-root fallback.
- `POST /angel-numbers/daily`: Daily-message endpoint.

### TypeScript SDK example

```typescript
roxy.angelNumbers.analyzeNumberSequence({ query: { number: '1111' } })
```

### Python SDK example

```python
roxy.angel_numbers.analyze_number_sequence(number='1111')
```

### PHP SDK example

```php
$roxy->angelNumbers->analyzeNumberSequence(number: '1111')
```

### C# SDK example

```csharp
roxy.AngelNumbers.Lookup.GetAsync(c => c.QueryParameters.Number = "1111")
```

## Location

- `GET /location/search?q={city}`: City search. Paginated envelope: `{ total, limit, offset, cities: [...] }`. Each city has `city`, `province`, `country`, `iso2`, `latitude`, `longitude`, `timezone` (IANA string, e.g. `"America/New_York"`), `utcOffset` (decimal hours, DST-adjusted for today), `population`. Chart endpoints accept `timezone` as either the IANA string or `utcOffset` decimal: both work, IANA is preferred because it resolves to the DST-correct offset for the request's `date`. Call first for any coordinate-dependent endpoint.

### TypeScript SDK example

```typescript
roxy.location.searchCities({ query: { q: 'New York' } })
```

### Python SDK example

```python
roxy.location.search_cities(q="New York")
```

### PHP SDK example

```php
$roxy->location->searchCities(q: 'New York')
```

### C# SDK example

```csharp
roxy.Location.Search.GetAsync(c => c.QueryParameters.Q = "New York")
```