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 each per-product OpenAPI spec at /api/v2/{slug}/openapi.json.

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

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

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

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

C# SDK example

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/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

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

Python SDK example

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

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

C# SDK example

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

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

Python SDK example

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

PHP SDK example

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

C# SDK example

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

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

Python SDK example

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

PHP SDK example

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

C# SDK example

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

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

Python SDK example

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

PHP SDK example

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

C# SDK example

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

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

Python SDK example

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

PHP SDK example

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

C# SDK example

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

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

Python SDK example

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

PHP SDK example

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

C# SDK example

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

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

Python SDK example

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

PHP SDK example

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

C# SDK example

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

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

Python SDK example

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

PHP SDK example

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

C# SDK example

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

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

Python SDK example

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

PHP SDK example

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

C# SDK example

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

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

Python SDK example

roxy.tarot.draw_cards(count=3)

PHP SDK example

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

C# SDK example

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

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

Python SDK example

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

PHP SDK example

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

C# SDK example

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

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

Python SDK example

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

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

C# SDK example

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

roxy.iching.castReading({})

Python SDK example

roxy.iching.cast_reading()

PHP SDK example

$roxy->iching->castReading()

C# SDK example

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

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

Python SDK example

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

PHP SDK example

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

C# SDK example

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

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

Python SDK example

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

PHP SDK example

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

C# SDK example

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

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

Python SDK example

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

PHP SDK example

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

C# SDK example

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

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

Python SDK example

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

PHP SDK example

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

C# SDK example

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