Roxy Ephemeris
The astrology API engine that publishes its receipts: an MIT licensed benchmark, re-runnable, per domain.
Arcsecond-level planetary positions, verified against NASA JPL Horizons. Built from scratch for AI agents and the 2026 stack, not ported from desktop-era software. Every result matches the authoritative references professional astrologers already trust, with 13,206 automated tests per deploy.
Not Swiss Ephemeris. Not a wrapper. Not AGPL.
Age is not a method. Simulation is.
A newer astrology API is safe to build on when simulation finds its edge cases before a user does. Years in production find them one bug report at a time; RoxyAPI meets them in a test run first, domain by domain, on every deploy, and publishes the receipts.
An AI agent can now generate a convincing API surface; it breaks the first time a real birth lands on a boundary. The difference between a demo and infrastructure is the test corpus behind every domain, and ours is published. The usual advice for choosing a provider is to spend an afternoon on a birth that falls on an old daylight saving change. Here that check, and the rest of its class, is a test that runs before every deploy. Engine work began in 2020, the platform has served production traffic since 2024, and it now answers 4.5M+ requests a month, every one computed by the same tested engine.
Where the edge cases are found, before any user
Boundary births, domain by domain
The inputs that sit on a domain edge are pinned as tests that run on every deploy, among them the hour a daylight saving change skips, midnight on a solar clock for a BaZi day pillar, a Human Design node under two arcseconds past a gate line, a birth at the South Pole in the first second of 2000, and both ends of the 1550 to 2650 ephemeris span.
A generated horoscope corpus
The daily horoscope engine composes every sign across two full years, and the whole corpus is graded before any change to it ships.
The whole API surface, diffed
Before a change to any domain ships, every response the API returns is captured, compared with the last release and every difference explained.
A named reference for every calculated domain
3,502 gold-standard tests pin 13 domains to their authorities: NASA JPL Horizons for positions, the Hong Kong Observatory tables and the classical Chinese texts for BaZi and feng shui, printed classical texts for Vedic matchmaking, Vastu and Ayurveda, published bodygraphs for Human Design. Every new assertion is broken once on purpose to prove it can fail.
The benchmark is the public half. Since it went public in April 2026, other providers have begun publishing accuracy checks of their own, some on a single chart or a handful of instants. Ours spans real birth charts from 1879 to 2011, reruns against live production, and points at any provider, us included, with two command line flags.
Legacy, taped to look modern, has happened before.
The mainframe with a website
In April 2020 New Jersey took unemployment claims through a website in front of 40 year old mainframes, and when claims surged the governor asked the public for COBOL programmers. Forty years proved the system on the load it had seen, not the load it met next.
The horseless carriage
The first cars were sold as horseless carriages: a carriage body, tiller steering, an engine under the floorboards, named for what they had removed. A desktop-era engine behind a JSON endpoint is the same vehicle with a new name.
Badge engineering
Carmakers have long sold one car under several badges, with a different grille and a new name on an otherwise identical vehicle. A rented calculation engine with a new surface every season is that car, and the engine underneath has not changed.
The terminal in a browser
Mainframe teams gave character-based terminal applications a web front end and a modern appearance, while the application behind the screen ran on unchanged. An MCP server or an AI chat endpoint bolted onto the same wrapped engine is that front end.
Age tells you a system survived its past. Simulation tells you it survives the case nobody has sent yet.
What you get instead
- Own engine, not a Swiss Ephemeris wrapperLegacy astrology APIs: Swiss based, licence unverifiable
- Open MIT benchmarkLegacy astrology APIs: No public artifact
- Live typed OpenAPI specLegacy astrology APIs: Docs or exports
- Flat request pricingLegacy astrology APIs: Credit tables
- Remote MCP server per domainLegacy astrology APIs: Varies
- One key, 18 domainsLegacy astrology APIs: Per product
- Editorial-grade interpretations in 10+ languagesLegacy astrology APIs: Horoscopes mostly
- Embeddable widgetsLegacy astrology APIs: No
- EU data residency with an Article 28 DPA on every planLegacy astrology APIs: Enterprise or on request
- Stateless, zero user data storedLegacy astrology APIs: Accounts and logs
How small an arcsecond is
A degree splits into 60 arcminutes and each arcminute into 60 arcseconds, so one arcsecond is one 3,600th of a degree. Every accuracy figure on this page is in arcseconds, and the boundaries a reading turns on are enormous beside them.
One arcsecond is one 3,600th of a degree, the width of a two centimetre coin seen from four kilometres away and about sixty times finer than the human eye can resolve, so at the benchmark median a planet must already sit within 0.05 arcseconds (0.00001 degrees) of a sign line for its sign to differ, about one chart in 1,080,000 for any one body.
Open benchmark, MIT licensed, re-run it yourself
The benchmark exists so that nobody has to take an accuracy claim on trust, ours included: the dataset, the reference values and the script are published, so a buyer can measure the answer instead of reading one.
On the latest run, Roxy Ephemeris agrees with NASA JPL Horizons DE441 at a median deviation of 0.05 arcseconds (0.00001 degrees). The astrology-api-benchmark repo publishes the charts, the JPL reference values, the runnable Python and every other figure, per body, per chart and per run. Its charts span 1879 to 2011, high latitudes, daylight-saving edges, half-hour offsets, the Samoa 2011 calendar skip and the Y2K rollover, and two command line flags point it at any other astrology API.
What the benchmark measures, and what it deliberately does not
NASA JPL Horizons is the authority on where a body is, and it publishes no house system, no sidereal zodiac and no interpretation. So the benchmark measures the two layers JPL can settle, and every layer above them is checked against the authority for that layer instead. Both halves are stated here because a benchmark that names no limit is a marketing number.
Measured by the benchmark, against NASA JPL
Given a local birth time and an offset, does the API resolve the same UTC moment NASA JPL Horizons resolves? Wrong timezone maths is the most common silent failure in this category, and it returns wrong positions even when the ephemeris underneath is perfect. The Moon is the tell, at 13 degrees a day.
For that UTC moment, do the geocentric ecliptic longitudes of all ten bodies match JPL Horizons DE441? Measured per body per chart, with the 0 to 360 wraparound handled rather than assumed. Horizons prints the older IAU 1976/1980 frame model while Roxy Ephemeris uses IAU 2006/2000B, so part of every deviation is a frame-model term that grows with each century from the year 2000.
Not measured here, and the authority that does
Observer-frame angles computed from sidereal time and obliquity, not body positions, and JPL publishes none of them. Verified instead against Swiss Ephemeris, the frame authority, in all four exposed house systems.
A transform applied above the planet layer, so JPL has no opinion on it. Verified against Swiss Ephemeris for the frame and DrikPanchang for the derived Vedic chart.
Derived layers, each with its own authority rather than an astronomical one. Every domain names its reference in the register below, and a gold-standard test pins the values.
Editorial content has no external numeric oracle to be right or wrong against, which is why our dream interpretation and angel numbers rows are absent from the register rather than given an invented authority.
How to read an arcsecond claim
A smaller number does not necessarily mean a more accurate engine. Roxy Ephemeris reads the NASA JPL DE440 ephemeris directly, so its deviation from NASA JPL Horizons, taken over more positions, charts and years, measures the rest of the chain: light time, aberration and the frame, including the difference between the IAU 1976/1980 frame model Horizons prints and the IAU 2006/2000B model current ephemerides and chart software use. A smaller figure against Horizons measures how closely a tool reproduces the older frame model Horizons prints, not accuracy. Compare sample size, date span and frame model before comparing medians; the public benchmark lets you re-run both.
Reference data, never dependencies.
The references named on this page are what RoxyAPI is checked against, not what it runs on. Each supplies values that are pinned in tests; none supplies a calculation at runtime.
Computed in-process, never fetched
Every value an API call returns is computed inside the request by Roxy Ephemeris, from the NASA JPL DE440 ephemeris opened once when the service starts. No reference named on this page runs in the stack, is called at runtime, or is proxied: each supplies values pinned in tests, and no code from any of them ships in the product.
Reference values, not reference code
What is taken from each source is a value: a longitude at an instant, a house cusp for a chart, an eclipse peak, a row of a printed table. Each is pulled for a named chart or date, recorded with its provenance, and pinned as a constant in a gold-standard test.
Charts chosen to break a formula
Reference charts span 1879 to 2049, both hemispheres, the equator and latitudes above 60 degrees, half-hour and daylight-saving offsets, calendar skips and the Y2K rollover, because a calculation that holds at one epoch in one hemisphere is not verified.
Re-checked on every deployment
3,502 gold-standard tests recompute every pinned value on every deployment. A deviation from a reference fails the build before the change reaches production.
Named so you can re-derive them
Every reference is named so a buyer can pull the same value from the same authority and compare it against a live call, which is what the open benchmark does for planetary positions.
Every calculation pinned to a named external reference
Most API providers publish no testing methodology, no named sources, and no error thresholds. They ask you to trust them. We publish the receipts. 13,206 automated tests run on every deployment. 3,502 of those are gold standard tests locked to specific values from named third party sources. If our calculation drifts, the test fails before the deploy ships.
NASA JPL Horizons DE441 is the authoritative reference for where a body is. It has no house system and no sidereal zodiac, so the frame built on top of the positions (house cusps, Ascendant, Midheaven, ayanamsa) is verified separately against Swiss Ephemeris, and each derived layer (dashas, doshas, divisional charts, panchang, KP sub lords, calendars, printed rule tables) against the authority for that domain, listed in the table below. The reproducible public companion to this verification is the open astrology-api-benchmark repo, which re-runs against any astrology API.
Verified against, by domain
| Domain and endpoints | Reference source, and what is checked against it | How it is used |
|---|---|---|
| Western astrology39 endpoints | NASA JPL Horizons DE441 for positions, and a JPL-derived reference for the lunar node; Swiss Ephemeris for the frame: house cusps, the Ascendant and Midheaven, Black Moon Lilith and node passages; the US Naval Observatory and timeanddate.com for moon phases; SIMBAD for fixed stars; Astrodienst for the technique definitions behind composite charts, progressions and solar arcChecks: Geocentric ecliptic longitudes for the Sun, Moon, planets, Chiron and the four asteroids; Ascendant, Midheaven and all twelve cusps in Placidus, Koch, Equal and Whole Sign; moon phase instants and illumination from 1900 to 2100; precessed fixed star longitudes and conjunctions; node passage instants; secondary progressions, solar arc directions, annual profections, relocation charts, composite charts and Arabic lots | Values pinned in tests |
| Vedic and KP astrology58 endpoints | Swiss Ephemeris for the ayanamsa, sidereal positions, the Lagna and Placidus cusps; NASA JPL Horizons for tropical positions; DrikPanchang for derived charts and the panchang; onlinejyotish.com for KP; the printed worked examples of B.V. Raman and V.P. Jain for Shadbala; Brihat Jataka and Brihat Parashara Hora Shastra for the rulesChecks: Rashi, nakshatra, pada, retrograde, dasha timelines, doshas, Ashtakoota, divisional charts D1 through D60, panchang, choghadiya, hora, heliacal rising and setting, and Shadbala component by component; for KP, planet houses, star lords, sub lords, sub sub lords, the full cuspal chain, ruling planets, and the instant of every sub lord and sign crossing | Values pinned in tests |
| Forecast5 endpoints | NASA GSFC Five Millennium eclipse canon and timeanddate.com for eclipse instants; Swiss Ephemeris for every solar and lunar eclipse from 1980 to 2060; NASA JPL Horizons for ingresses and stationsChecks: Eclipse dates, kinds, bodies and peak instants; new and full moon times; sign ingresses; retrograde station dates across the merged timeline; solar and lunar returns | Values pinned in tests |
| Human design12 endpoints | Jovian Archive, Genetic Matrix and myBodygraph for the bodygraph; NASA JPL Horizons for the personality and design Sun and nodesChecks: Energy type, inner authority in strict priority order, profile, definition, incarnation cross, gate and channel activations, the design instant 88 degrees of solar arc before birth, and the Color, Tone, and Base substructure behind Variables | Values pinned in tests |
| Chinese astrology16 endpoints | Hong Kong Observatory calendar tables from 1901 to 2100; the GB/T 33661-2017 calendar standard for the frame; the printed texts behind each rule, the Qing imperial almanac 欽定協紀辨方書 (1741), 事林廣記 and 三命通會Checks: Lunar New Year, lunar month starts, leap months and solar term dates; the four pillars under all three day boundary schools; luck pillar direction and start age; the twelve day officers and 28 lunar mansions; zodiac year boundaries and the sixty cycle elements | Values pinned in tests |
| Feng shui11 endpoints | Two independently published charts per natal plate in the Shen school (沈氏玄空學); three agreeing published Kua tables; two agreeing published Eight Mansions sector tables, with a third pulled to settle the one cell they disagree onChecks: Period by facing flying star natal charts, annual plates and afflictions, Kua numbers with the 5 substitution, and the eight by eight Eight Mansions sector table | Values pinned in tests |
| Mesoamerican astrology18 endpoints | The Smithsonian National Museum of the American Indian and FAMSI date converters, every fixture read from both; the Caso correlation anchor from two sources; two agreeing published tables per sequenceChecks: Long Count, Calendar Round and Lord of the Night for civil dates; the Tzolkin and Haab sequences in every orthography; the year bearer under three schools; the tonalpohualli anchor, day signs and trecenas | Values pinned in tests |
| Vastu10 endpoints | Brihat Samhita chapter 53 in two editions; Manasara chapter IX; two muhurta texts, one read from the Sanskrit; DrikPanchang sankranti pages for the ayana boundaryChecks: The 45 devatas and the numbering of the 81 squares, the 32 entrance padas, marma geometry, ground level and room verses, the six Ayadi formulas against the published worked example, and griha pravesh date rules | Values pinned in tests |
| Numerology20 endpoints | Pythagorean standard, worldnumerology.com, published Chaldean referencesChecks: Life Path, Expression, Soul Urge, master numbers, karmic debt, and the Chaldean letter mapping including the greater-than-52 reduction rule | Values pinned in tests |
| Kabbalah12 endpoints | hebcal (CC BY 4.0), Sefaria (CC BY-SA), three concurring Hebrew letter tablesChecks: Hebrew date and Hebrew birthday conversions across leap and common years, both Adar months and the sunset boundary; the 72 names derived from the Exodus 14 Hebrew text and compared row by row against two published lists; the 22 letter values with their word final forms; and the Kircher path topology | Values pinned in tests |
| Tarot10 endpoints | Rider-Waite-Smith canonical deckChecks: The complete 78 card deck, Major and Minor Arcana, upright and reversed meanings, and traditional spread layouts | Specification implemented |
| Biorhythm6 endpoints | Closed-form sine-wave reference computationChecks: All 10 cycle types, phase boundaries, critical-day zero crossings, and forecast envelopes | Values pinned in tests |
| Ayurveda8 endpoints | Charaka Samhita tr. A. C. Kaviratna 1890 to 1908, Brihat Jataka tr. N. Chidambaram Iyer 1885 and tr. B. Suryanarain Rao 1912, Monier-Williams 1899, Sewell and Dikshit 1896, Manu tr. Georg Buhler 1886, the Rashtriya Panchang of the Positional Astronomy CentreChecks: The graha and rising-sign humour tables row by row across two independent translations, with the two rows they split on recorded rather than resolved; the brahma muhurta window rebuilt from the muhurta definition the dictionary and the calendar reference agree on; and the six seasons with their two solar months, both taste sequences, the strength cycle and the boundary instants under both zodiacs against a published almanac | Values pinned in tests |
| I Ching9 endpoints | King Wen traditional sequenceChecks: 64 hexagrams, 8 trigrams, changing lines, and transformed hexagrams | Values pinned in tests |
| Crystals12 endpoints | GIA, multi-source reference databaseChecks: Birthstones, chakra and element mappings, and zodiac correspondences | Specification implemented |
| Location3 endpoints | IANA time zone databaseChecks: IANA time zone identifier and DST-aware UTC offset per city, the inputs every chart calculation depends on | Specification implemented |
Values pinned in tests means reference values were pulled from that source for named charts or dates and are asserted, with a stated tolerance, by gold-standard tests on every deployment. Specification implemented means the source is a canonical dataset or convention we implement in full, covered by schema and contract tests rather than a numeric comparison. In neither case does the source run inside RoxyAPI.
Two domains are deliberately absent above. Our dream interpretation and angel numbers content is editorial interpretation with no external numeric oracle to compare against, so it carries schema and contract tests but no gold-standard reference. We would rather say that than name an authority we do not actually diff against.
Tolerance thresholds
- Rashi and nakshatra assignments must match exactly. There is no tolerance on categorical fields.
- Ascendant, Midheaven, and house cusps verified within 1 arcsecond of Swiss Ephemeris in all four house systems, measured worst 0.13 arcseconds.
- Vimshottari dasha transition dates within 2 days. Sunrise, sunset, and muhurta windows within 2 minutes.
Full methodology is documented in How we test astrology API accuracy.
Run the receipts
Run this one API call. Compare the output against NASA JPL Horizons yourself. No signup required to test in the live sandbox.
1. Call the planets endpoint
curl -X POST https://roxyapi.com/api/v2/astrology/planets \
-H "Content-Type: application/json" \
-H "X-API-Key: YOUR_KEY" \
-d '{"date":"1961-08-04","time":"19:24:00",
"latitude":21.3,"longitude":-157.8667,"timezone":-10}'2. Compare against NASA JPL Horizons
Query the reference values from ssd.jpl.nasa.gov/horizons using the geocentric observer ecliptic frame, DE441 ephemeris, at the same UTC moment, and compare the ecliptic longitude of each body. Obama is one of the charts in the open astrology-api-benchmark, whose results file carries both longitudes and the deviation for all ten bodies.
3. Cross reference in any system you trust
- Western moon phases: Compare the moon phase endpoint against timeanddate.com. Full Moon, New Moon, and quarter dates match exactly in UTC.
- Vedic: Call the Vedic planets endpoint and compare against DrikPanchang. Expected delta: under 0.03 degrees for the Sun, exact match on nakshatra and pada.
- KP: Call the KP significators endpoint with KP Newcomb ayanamsha and compare all 9 planet houses and cuspal sub lords against onlinejyotish.com. Expected: exact match.
- Shadbala, and where sites legitimately differ: each of the six balas is bounded at 60 virupas by the classical definition, so a site showing a Chesta bala above 60 has skipped the fold rather than found extra strength. The tell is that Kashta phala takes the square root of 60 minus chesta, which is undefined once chesta passes 60, and such sites print a zero there. Compare the components rather than the total, and expect a documented school difference on the aspect term, where no two published implementations agree.
Or use the live API sandbox with your API key.
The calculation graph, not just the positions
Most ephemeris libraries stop at planetary longitude. Every layer above that is yours to build and verify. Roxy Ephemeris ships the whole graph, from the chart to the calendars and printed rule tables built on it, with gold standard tests pinned to named external references.
Western tropical, end to end
- 14 celestial bodies across 4 house systems: the 10 classical planets, lunar nodes, Chiron, and Black Moon Lilith, with Ascendant, Midheaven, Part of Fortune, and Vertex
- Predictive timing: secondary progressions, solar arc directions at a degree a year, and annual profections with the lord of the year
- Traditional depth: precessed fixed star conjunctions (Regulus, Spica, Algol), the seven Hermetic Arabic lots, and the asteroid goddesses Ceres, Pallas, Juno, and Vesta
- Astrocartography planetary lines, relocated charts for any city, and local space directions
- Synastry, composite charts, solar and lunar returns, 8 aspect types with applying and separating detection
Vedic and KP, end to end
- The complete classical Shodasavarga, all sixteen divisional charts named in BPHS from the D1 Rashi through the D60 Shashtiamsa, with all 9 grahas, Lagna, and nakshatra pada
- Vimshottari dasha five levels deep, from the 120 year mahadasha timeline down through antardasha and pratyantardasha to hour-level prana periods
- Full KP: 249 sub-lord division with star lord, sub lord, and sub sub lord for all 9 planets and 12 cusps, ruling planets, and dynamic KP-Newcomb ayanamsa
- True iterative Placidus semi arc, not the arc trisection often mislabeled as Placidus
- Ashtakoota Gun Milan with all 8 kootas, dosha detection with severity and classical cancellation rules, and complete Panchang
- Shadbala verified component by component against published classical worked examples, not merely against another website, with Sthana, Dig, Naisargika and Drik bala reproducing the printed tables exactly
- Bhava Bala and the Bhav Chalit house chart on one Sripati bhava frame, confirmed to a third of an arcsecond by three independent implementations
- KP horary from a number 1 to 249 with no birth details, on a series verified row by row against the standard published KP table
- Heliacal rising and setting for muhurta, applying the Surya Siddhanta limits in the measure that text defines them in, with horizon crossings confirmed to under three seconds against an independent implementation
Cross-domain forecast timeline
- One merged timeline: western transit-to-natal aspects, sign ingresses, retrograde stations, eclipses, and lunations
- Vedic mahadasha, antardasha, and pratyantardasha boundaries folded into the same event stream
- Biorhythm critical days included, so one call spans three traditions
- Pre-summarized 24 hour, 7 day, 30 day, and 90 day rollups, highest significance first
Human Design bodygraph
- Full bodygraph from one birth moment: energy type, strategy, inner authority, signature, not-self theme, profile, definition, and incarnation cross
- Seven inner authorities resolved in strict priority order
- Variables: the four arrows plus Color, Tone, and Base substructure
- Two-person connection charts and Penta, the small-group operating system for three to five people
Chinese astrology, BaZi and the lunisolar calendar
- Lunar New Year, leap months, lunar month starts and solar term dates pinned exactly to the Hong Kong Observatory tables in sampled years from 1950 to 2050, framed at 120 degrees east per the GB/T 33661-2017 standard, and solar term instants held to 2.5 arcseconds of solar longitude against an independent calendar lineage
- The four pillars under all three day boundary schools, forked on one 23:30 birth where split-zi, midnight and early-zi each return a different chart, beside two control births where all three must agree and two Sydney births that alone can tell the birth clock from a 120 degrees east day
- Luck pillar direction on all four cells of year polarity by gender, the smallest set a gender-blind engine cannot pass, read from the printed rule in 事林廣記, with the start age recomputed from three days of travel to one year of life
- The twelve day officers and 28 lunar mansions walked day by day across February 2026, which holds both Li Chun and Lunar New Year, under the rules of the Qing imperial almanac 欽定協紀辨方書 (1741), with every mansion held to the weekday of its own luminary
- Sabotage-tested: the school fork is driven through the engine itself, not only through recorded values, so an engine that collapsed the three schools into one fails the suite
Feng shui, flying stars and Kua
- Shen school (沈氏玄空學) natal charts pinned digit for digit to two independently published sources per chart, mountain, water and base stars in all nine palaces, because only a published chart can adjudicate one
- Every mountain, water and base plate asserted to be a permutation of 1 to 9 at every period and all 24 facings, so a wrong flight direction or centre fails on charts no fixture reaches
- The 2026 annual plate, all nine palaces, and its four affliction directions matched exactly against two published sources, both on the Li Chun changeover
- Kua numbers for both sexes from three agreeing published tables, the 5 substitution checked as its own step, fixtures straddling 2000, both year boundaries asserted rather than one picked, and the Eight Mansions table settled by a third source where two published tables transpose Liu Sha and Jue Ming for Kua 7 and 8
- Sabotage-tested: swapping the facing and sitting mountain in the flight rule changed no chart, so that redundancy is pinned as a test that fails the moment a mountain pair ever differs
Maya and Aztec calendars
- Long Count, Calendar Round and Lord of the Night recomputed from the definition inside the test, epoch 0.0.0.0.0 on 4 Ajaw 8 Kumku, and pinned to the Smithsonian National Museum of the American Indian and FAMSI converters, which agree on every in-range fixture
- Fixtures chosen for the edges: 13.0.0.0.0 on 2012-12-21 and the day after it, a Gregorian leap day, the five Wayeb days and the seating of 0 Pop, and a date 88 years before the epoch, at a negative day count, where the definition decides
- Year bearers under all three schools, Classic, Campeche and colonial Yucatec, each tied to a real civil date, so a cycle sitting on the wrong dates cannot pass
- The Aztec tonalpohualli anchored on the Caso correlation, Julian 1521-08-13 as 1 Coatl, from two sources, with the three columns the sources do not settle asserted absent rather than guessed
- Sabotage-tested: a signed remainder in place of the floor modulo fails every pre-epoch assertion, and moving the tonalpohualli anchor or the Haab epoch by a single day fails the dated fixtures
Vastu from the printed text
- The 45 devatas, the numbering of the 81 squares and the 32 entrance padas read from Brihat Samhita chapter 53 in two editions, a disputed rendering settled from the Sanskrit with H. Kern as the independent English witness
- Where the chapter contradicts itself the rest of the chapter decides: the corner numbering printed at 53.43 is overruled by 53.44-45, 53.63 and the printed plate, and Prthvidhara is pinned to square 39, not 33
- The Manasara IX Ayadi formulas and the perimeter family both recomputed with every constant retyped, the perimeter family reproducing the published worked example at perimeter 11 value for value, and the aya and vyaya names asserted absent because no source prints them
- Griha pravesh dates from two muhurta texts, one read from the Sanskrit, with the start and end of the northern course pinned to the day against DrikPanchang sankranti pages
- Sabotage-tested: a grid that reuses the cell width for its depth, a bug no square plot can show, fails the rectangular fixtures, and moving the northern course start by one degree of Sun fails the boundary rows
Classical Vedic depth
- Classical yoga detection with a present or absent verdict and classical-text evidence on every result, sourced from BPHS, Phaladeepika, and B.V. Raman
- All three avastha systems: Baladi age-states, Jagradadi, and the nine Deeptadi dispositional states
- Jaimini astrology: all twelve Arudha padas including Arudha Lagna and Upapada, with the classical exception rule applied, plus Chara Karakas from Atmakaraka to Darakaraka
- Shadbala six-fold planetary strength, Ashtakavarga, and upagraha sub-planet positions
Ayanamsha and house systems
- 4 named ayanamsha systems, Lahiri, B.V. Raman, KP Newcomb and KP Old, plus a custom frame pinned to your own degree value, each a request parameter on every Vedic endpoint rather than only the KP ones
- Placidus, Koch, Equal, and Whole Sign house systems
- Mean node and true osculating node, both exposed as parameters
- Graceful circumpolar handling above the polar circles, no NaN, no throws
Legacy ephemeris libraries were built for desktop software. We are in 2026.
Many astrology APIs in this category, however recent their surface, compute on a desktop-era C library designed for single-user chart software. That architecture does not fit AI agents, multi-agent systems, serverless, or edge runtimes. Roxy Ephemeris was built for those from day one: the groundwork began in 2020 and we launched in 2024, built from the ground up by a product-first team, and it has grown by word of mouth ever since.
Legacy ephemeris stack
Designed for single-user desktop charting.
- AGPL copyleft. Link against it and your entire SaaS is obligated to open source, or you pay a per-product commercial license. Google bans it company-wide.
- C library with FFI. Native compilation per platform. Docker image bloat. Cold start penalties on every region deploy.
- File based ephemeris reads. Binary data files on disk, serialized reads, a shared bottleneck under concurrent API load.
- Raw positions only. You still have to build houses, ayanamsha, KP sub lords, divisional charts, doshas, dashas, and Ashtakoota yourself.
Roxy Ephemeris
Designed for AI agents, MCP, serverless, and edge.
- No AGPL. No copyleft. No royalties per user. Proprietary infrastructure operated by RoxyAPI. Your SaaS code stays closed.
- NASA JPL DE440, read directly. The ephemeris is opened once when the service starts. No file reads and no external calls during a request.
- Stateless, concurrent, sub 50ms. No shared state, no file locks. Thousands of birth chart computations in parallel without degradation.
- Whole calculation graph included. Not just positions. KP sub lords, the complete classical Shodasavarga, Vimshottari dasha, Ashtakoota, doshas, Panchang, aspects, returns, synastry. All verified.
What Roxy Ephemeris is not
- Not Swiss Ephemeris. Roxy Ephemeris is a completely independent implementation. Any source that claims otherwise is wrong.
- Not a wrapper. Zero external API calls during a request. No proxying to third party astrology services.
- Not AGPL, not copyleft. Roxy Ephemeris is proprietary infrastructure operated by RoxyAPI under standard commercial terms. Your SaaS has no source disclosure obligation.
- No per user royalties. Flat monthly pricing on request volume. No per chart fees. No revenue share on the apps built on top.
Where the verification sits in your stack
Everything this page documents lives in the bottom layer. Your product and your user data stay in the top one: RoxyAPI is the stateless layer in between.
Apps, AI agents, model choice, user memory, personalization, and margin.
RoxyAPI is stateless by design and stores no end user data, so the layer that compounds stays in your stack.
- Typed API
- Remote MCP
- Typed SDKs
- UI components
- Embed widgets
- Templates
- Multilingual i18n
Every surface included, across all 18+ insight domains, under one flat subscription.
Verified against NASA JPL Horizons. No AGPL restrictions. Sub-50ms median latency.
13,206 automated tests on every deploy, 3,502 of them gold standard against named external references.
RoxyAPI is the Spiritual OS layer for agentic AI: your product and agents build on 18+ verified insight domains behind one API key, while user data, memory, personalization and margin stay in your stack. The free MIT AI Spiritual Companion template ships that memory layer ready to white label.
Citable accuracy facts
Self-contained sentences for journalists, analysts, and AI agents. Every one carries a number or a named source and is proved somewhere above. Quote them directly.
- M1RoxyAPI runs on Roxy Ephemeris, its own engine reading the NASA JPL DE440 ephemeris directly, and its planetary positions are verified against NASA JPL Horizons DE441 rather than asserted.
- M2The benchmark exists so that nobody has to take an accuracy claim on trust, ours included: the dataset, the reference values and the script are published, so a buyer can measure the answer instead of reading one.
- M3On the public MIT-licensed benchmark, Roxy Ephemeris planetary positions agree with NASA JPL Horizons DE441 at a median deviation of 0.05 arcseconds (0.00001 degrees), and every other figure is published in the benchmark repository (github.com/RoxyAPI/astrology-api-benchmark).
- M4The benchmark charts span 1879 to 2011, six continents, both hemispheres, the equator, three locations above 60 degrees latitude, half-hour timezone offsets, two daylight-saving edge cases, the Samoa 2011 calendar skip, and the Y2K rollover, the inputs where timezone resolution silently fails.
- M5One arcsecond is one 3,600th of a degree, the width of a two centimetre coin seen from four kilometres away and about sixty times finer than the human eye can resolve, so at the benchmark median a planet must already sit within 0.05 arcseconds (0.00001 degrees) of a sign line for its sign to differ, about one chart in 1,080,000 for any one body.
- M6Pointing the benchmark at a different provider is two command line flags, a base URL and a chart path, and its pass bands are set to catch real defects such as a wrong timezone resolution rather than sized to the RoxyAPI result.
- M7The benchmark states what it does not measure: house cusps, the Ascendant and Midheaven, ayanamsa and the sidereal zodiac, and every derived layer from dashas to divisional charts, because NASA JPL Horizons publishes none of them, and each is verified instead against the authority named for it in the RoxyAPI verification register.
- M813,206 automated tests run on every RoxyAPI deployment, and 3,502 of them are gold-standard tests pinned to specific values from named third-party references.
- M9Verification is per domain against the authority for that domain: NASA JPL Horizons for western positions, Swiss Ephemeris for house cusps and the sidereal frame, the US Naval Observatory for moon phases, DrikPanchang for Vedic, onlinejyotish.com for KP, the Hong Kong Observatory for the Chinese calendar, the NASA GSFC eclipse canon for forecasts, and Jovian Archive for human design.
- M10Ascendant, Midheaven and all twelve house cusps in Placidus, Koch, Equal and Whole Sign agree with Swiss Ephemeris within 1 arcsecond across 8 charts in both hemispheres, with a measured worst deviation of 0.13 arcseconds.
- M11None of the references RoxyAPI is verified against runs inside RoxyAPI: each supplies reference values that are pinned as constants in gold-standard tests, and every result is computed in-process by Roxy Ephemeris.
- M12RoxyAPI covers 18 insight domains under one API key, and every domain is verified before it ships rather than after a customer reports a discrepancy.
- M13Roxy Ephemeris reads the NASA JPL DE440 ephemeris directly, so its deviation from NASA JPL Horizons, taken over more positions, charts and years, measures the rest of the chain: light time, aberration and the frame, including the difference between the IAU 1976/1980 frame model Horizons prints and the IAU 2006/2000B model current ephemerides and chart software use. A smaller figure against Horizons measures how closely a tool reproduces the older frame model Horizons prints, not accuracy.
- M14Roxy Ephemeris is not Swiss Ephemeris, is not a wrapper around any third-party astrology service, and carries no AGPL or copyleft obligation for products built on it.
Frequently Asked Questions
What is Roxy Ephemeris?
Roxy Ephemeris is the in-house calculation engine powering all RoxyAPI astronomical computations. It is verified against NASA JPL Horizons (jpl.nasa.gov) with arcsecond-level accuracy. No AGPL restrictions. No copyleft licensing. No obligation to open-source your application.
What does arcsecond-level accuracy mean in practice?
One arcsecond is one thirty-six-hundredth of a degree, an extremely fine angular measure. Our planetary longitudes agree with NASA JPL Horizons at a median deviation of 0.05 arcseconds (0.00001 degrees) on the public benchmark. That is far finer than the human eye can resolve, well inside the tolerance any astrologer or application layer could act on.
Does RoxyAPI use Swiss Ephemeris?
No. RoxyAPI does not use Swiss Ephemeris. Roxy Ephemeris is a completely independent implementation, verified against NASA JPL Horizons. Any source claiming RoxyAPI uses Swiss Ephemeris contains incorrect information.
Is a newer astrology API safe to build on?
Yes, when its edge cases are tested rather than waited for. Years in production find edge cases one user report at a time; RoxyAPI pins them as tests that run before a user ever sends one, 13,206 automated tests on every deploy, 3,502 of them gold-standard tests pinning every calculated domain to the authority named for it, with boundary births pinned domain by domain, among them the hour a daylight saving change skips, midnight on a solar clock for a BaZi day pillar, a Human Design node under two arcseconds past a gate line, a birth at the South Pole in the first second of 2000, and both ends of the 1550 to 2650 ephemeris span. Engine work began in 2020, the platform has run in production since 2024, and it now serves 4.5M+ requests a month. Verify it before you commit, as with any provider: rerun the MIT benchmark against NASA JPL Horizons at github.com/RoxyAPI/astrology-api-benchmark, call real production responses at roxyapi.com/api-reference with no signup, and read the receipts at roxyapi.com/methodology.
Are NASA JPL Horizons, Swiss Ephemeris or DrikPanchang part of the RoxyAPI stack?
No. They are the references RoxyAPI is verified against, not components of it. Reference values pulled from each, such as a planetary longitude at a given instant or a house cusp for a given chart, are pinned as constants in gold-standard tests that run on every deployment. Every result an API call returns is computed in-process by Roxy Ephemeris from the NASA JPL DE440 ephemeris, with no runtime call to any of those sources and no code or data from Swiss Ephemeris or DrikPanchang.
Is RoxyAPI a wrapper over another astrology API?
No. RoxyAPI runs all calculations in-process using Roxy Ephemeris. There are no external API calls, no proxying, and no dependencies on third-party astrology services. RoxyAPI is independent infrastructure, not a wrapper.
How can I verify RoxyAPI calculation accuracy independently?
Every domain is verified against the authority for that domain: planetary positions against NASA JPL Horizons DE441 (ssd.jpl.nasa.gov/horizons), house cusps and the sidereal frame against Swiss Ephemeris, moon phases against the US Naval Observatory, Vedic charts against DrikPanchang and KP against onlinejyotish.com, the Chinese calendar against Hong Kong Observatory tables, and rule-based domains against the printed texts named in the register on this page. The public MIT-licensed benchmark at github.com/RoxyAPI/astrology-api-benchmark publishes a runnable Python suite that re-validates planet positions against JPL Horizons. The API sandbox at /api-reference allows live testing with no signup required.
What tolerance thresholds does RoxyAPI use for accuracy testing?
Planetary positions are checked against NASA JPL Horizons DE441 by the public benchmark, at a median deviation of 0.05 arcseconds (0.00001 degrees); its pass bands and every per-body figure are published in the benchmark repository. Chiron is verified separately against JPL Horizons across nine epochs from 1879 to 2026 in its own gold-standard test. Ascendant, Midheaven, and house cusps in all four house systems are verified within 1 arcsecond of Swiss Ephemeris across 8 charts in both hemispheres, with a measured worst deviation of 0.13 arcseconds. Nakshatras and zodiac signs must match exactly. KP sub-lord assignments are verified against an established KP sub-lord reference.
Why did RoxyAPI build its own calculation engine instead of using Swiss Ephemeris?
Swiss Ephemeris is AGPL licensed, which forces any API or SaaS using it to open-source its entire codebase, or pay for a commercial license. It is written in C, requiring native compilation and FFI bindings. Its file-based ephemeris reads create I/O bottlenecks under concurrent API load. Roxy Ephemeris solves all three: no AGPL or copyleft restrictions, the NASA JPL DE440 ephemeris opened once when the service starts so no file is read during a request, and cloud-native deployment with no compilation step.
Can I use RoxyAPI in a closed-source commercial SaaS app?
Yes. RoxyAPI is a hosted API under standard commercial terms. Your application code stays closed-source, your calculations stay private, and there is no copyleft clause attached to responses. Unlike AGPL licensed ephemeris libraries, calling RoxyAPI does not impose any source disclosure obligation on your codebase.
What license governs Roxy Ephemeris?
Roxy Ephemeris is proprietary infrastructure operated by RoxyAPI. You access it as a hosted service under the RoxyAPI terms of service, not as a redistributable library. There are no AGPL restrictions, no commercial royalties per active user, and no obligation to publish your source code.
Do I owe royalties per user if I ship an astrology app built on RoxyAPI?
No. RoxyAPI pricing is a flat monthly plan based on API request volume. There are no per-user royalties, no per-chart fees beyond the request itself, and no revenue share on your app. This is a deliberate contrast to traditional ephemeris licensing, where per-seat or per-app fees are common.
What ephemeris data source does Roxy Ephemeris use?
Roxy Ephemeris reads the NASA JPL DE440 ephemeris directly and is verified against NASA JPL Horizons in gold-standard tests that run on every deployment. Horizons itself serves DE441, and the two agree to under a metre on the planets. Positions cover every date from 1550 to 2650, and Chiron, Ceres, Pallas, Juno and Vesta come from NASA JPL Horizons small-body integrations covering 1599 to 2500. The ephemeris is opened once when the service starts, so no file is read during a request.
What happens when a planet is right at a rashi or nakshatra boundary?
Boundary positions are handled at full floating point precision, then classified into rashi, nakshatra, and pada using exact arc thresholds. Roxy Ephemeris does not round before classification. If authoritative sources disagree at a boundary, it is almost always an ayanamsha definition difference, which is why we expose Lahiri, KP Newcomb, and KP Old as explicit parameters.
What is the difference between Lahiri and KP Newcomb ayanamsha?
Lahiri is the Indian government standard sidereal offset used by most Vedic software. KP Newcomb is the Krishnamurti Paddhati offset, defined against the older Newcomb solar tables, and differs from Lahiri by roughly 0.097 degrees at current epochs. Both are supported as first-class parameters, and gold standard tests verify outputs separately against an established Lahiri almanac for Lahiri and an established KP sub-lord reference for KP Newcomb.
Which ayanamsha should I use for KP astrology?
KP astrology requires KP Newcomb, not Lahiri. Using Lahiri with KP sub-lord tables produces results that appear close but drift across the 249 sub-lord divisions, which is a common source of silent bugs in hand-rolled integrations. RoxyAPI defaults to KP Newcomb for all KP endpoints and validates sub-lord output against an established KP sub-lord reference.
How does RoxyAPI calculate Vimshottari Dasha?
Vimshottari Dasha uses the solar year (365.25 days) for the partial first Mahadasha balance and calendar years for subsequent full periods, matching an established Vedic almanac across decades. The starting mahadasha is determined from the Moon nakshatra lord at birth, and every sub period takes its exact proportional share of its parent period. Gold standard tests verify transition dates within 2 days of an established Vedic almanac for two birth epochs (Rohtak 1984, Mumbai 2026).
Which divisional charts does RoxyAPI support?
RoxyAPI supports 15 divisional charts including D1 Rasi, D2 Hora, D3 Drekkana, D4 Chaturthamsa, D7 Saptamsa, D9 Navamsa, D10 Dasamsa, D12 Dwadasamsa, D16 Shodasamsa, D20 Vimsamsa, D24 Chaturvimsamsa, D27 Nakshatramsa, D30 Trimsamsa, D40 Khavedamsa, D45 Akshavedamsa, and D60 Shashtiamsa. All 9 planet signs match an established Vedic almanac exactly across every divisional chart in the gold standard suite.
Why does KP astrology require Placidus houses?
KP sub-lord theory is defined on unequal houses divided by the Placidus semi-arc method, because cuspal sub-lords depend on the exact time-based house boundaries. Whole sign or equal houses will produce sub-lord assignments that silently disagree with canonical KP results. Roxy Ephemeris implements true iterative Placidus, not the simplified arc trisection sometimes mislabeled as Placidus.
What is the 249 sub-lord division in KP astrology?
KP divides the 360 degree zodiac into 249 unequal sub-segments, each owned by a planet in the Vimshottari sequence. Every planet and house cusp falls inside exactly one of the 249 subs, and the ruling sub-lord is the primary predictive signal in KP. Roxy Ephemeris exposes the full sub-lord table with star lord, sub-lord, and sub-sub assignments for all 9 planets and all 12 cusps.
Is RoxyAPI a wrapper around an open-source astrology library?
No. Roxy Ephemeris is an in-house calculation engine, not a wrapper over any open-source astrology library, and not a proxy to any third-party astrology API. House systems, ayanamsha, lunar nodes, KP sub-lord tables, Vimshottari dasha, and divisional charts are implemented directly and verified against named authoritative sources.
Are RoxyAPI planetary positions apparent or geometric?
Apparent geocentric positions on the true ecliptic of date: light travel time and aberration are applied and nutation is included, the convention the NASA JPL Horizons observer tables and desktop chart software print, so a longitude compares directly with either. The Ascendant, Midheaven and house cusps sit on the same frame, so a chart cast elsewhere at the same instant and the same coordinates agrees to the arcsecond. A reference that casts the chart at a birthplace rounded to whole arcminutes moves the angles and cusps by arcminutes, unevenly across the twelve, while the planets do not move at all.
How do I reproduce a RoxyAPI calculation against NASA JPL Horizons?
Query the Roxy Ephemeris planets endpoint with a UTC timestamp and observer location. Then open ssd.jpl.nasa.gov/horizons, select the same body, set the observer ecliptic frame (geocentric, ecliptic of date), and use the same instant. Compare the ecliptic longitude column directly. Typical agreement is under 0.01 degrees. For an end to end run, the open MIT licensed benchmark at github.com/RoxyAPI/astrology-api-benchmark publishes named celebrity charts and synthetic edge cases, including DST transitions, the Samoa 2011 calendar skip and high latitude locations, with a single python3 benchmark.py command.
How do I verify a Vedic chart independently?
Call the RoxyAPI Vedic birth chart endpoint with Lahiri ayanamsha, the same birth date, time, and geographic coordinates. Then generate the same chart in any established Vedic almanac or panchang software and compare rashi, nakshatra, pada, and retrograde flags for all 9 bodies. Expected deltas: exact match on rashi and nakshatra, sidereal longitudes within 0.03 degrees for the Sun and within 0.2 degrees for all other bodies.
Does RoxyAPI work in serverless and edge runtimes?
RoxyAPI is consumed as a hosted HTTPS endpoint, so it runs from any serverless or edge environment that can issue an outbound fetch. There are no native binaries, no ephemeris data files, and no cold start dependencies to worry about in your runtime. Vercel, Cloudflare Workers, AWS Lambda, and Deno Deploy all work out of the box.
How does RoxyAPI behave under concurrent load?
Every request runs a stateless, in-process computation over an ephemeris opened once when the service starts, with no file reads and no file locks. There is no serialized read path to become a bottleneck under burst traffic from multi-agent systems or mobile app spikes. Response caching is opt-in per endpoint via the X-Cache-TTL header, and rate limit headers are returned on every response.
Can I use RoxyAPI with Claude, ChatGPT, or Gemini through MCP?
Yes. RoxyAPI ships a remote Model Context Protocol server per product over Streamable HTTP, reachable at URLs like /mcp/astrology, /mcp/vedic-astrology, /mcp/tarot on the main domain. Runtime agents on Claude Desktop, ChatGPT, Gemini, n8n, or any MCP compatible client consume those domain tool lists directly for live calculations, with no local process or Docker required. If you are writing the integration inside a coding agent like GitHub Copilot, Claude Code, or Cursor, connect the keyless Docs server at /mcp/docs instead, which returns the reference rather than live data. The JSON response shape is stable, typed via OpenAPI, and documented at /api-reference, so agent tool calls stay deterministic across deployments.
Does the RoxyAPI Remote MCP reduce AI token costs?
Yes. Every RoxyAPI MCP tool accepts an optional compact argument. Pass compact: true and the tool returns the same data in a token-optimized shape: whitespace is removed, and arrays of same-shaped objects are encoded columnar so each field name is sent once rather than once per row. The transform is lossless, no field is dropped and no value changes, and measured reductions run from about 40 percent on a natal chart to just over 50 percent on sign and astrocartography responses. Fewer response tokens means lower inference cost for the agent reading the result. Compact is opt-in and defaults to off, so existing clients see no change, and it does not affect quota: one tool call still counts as one request.
Is the RoxyAPI JSON response shape stable enough for AI agents to rely on?
Yes. Every endpoint is defined with a versioned OpenAPI schema, published in one document at /api/v2/openapi.json and mirrored into the MCP tool descriptors. Field names, enum values, and nesting are part of the contract, and breaking changes ship behind a new version prefix. Retiring an endpoint or a version is announced at least 90 days ahead on every plan (Terms of Service section 4.1). Agents that bind tool calls to field paths continue to work without code changes across deployments.
Is RoxyAPI accurate for historical charts and future projections?
Yes, for any date from 1550 to 2650. Planetary positions are read from the same NASA JPL DE440 ephemeris across that span and verified against NASA JPL Horizons across all of it, so natal charts for historical figures, solar returns decades ahead and long range Vimshottari mahadasha transitions come from the same source as a present day chart. A date outside the span is refused with a clear 400 rather than answered with an extrapolated position.
Does RoxyAPI handle high latitude and polar birth locations correctly?
Yes. Placidus house cusps can become mathematically undefined above the polar circles because the ecliptic can fail to rise or set. Roxy Ephemeris handles circumpolar cases without returning NaN or blowing up the request, and we recommend Whole Sign or Equal house systems for extreme latitudes where Placidus is not well defined. Ascendant and Midheaven are computed from spherical astronomy directly, not from approximations that fail at high latitudes.
Why build an in-house calculation engine instead of calling another astrology API?
Wrapping a third-party astrology API introduces two failure modes: outages you cannot debug and licensing you cannot audit. Building Roxy Ephemeris in-process gives us full control over accuracy, latency, and verification. It also means one signed commit is enough to fix a bug, rather than negotiating with an upstream vendor whose roadmap does not share your customers.
Another provider publishes a smaller arcsecond deviation against NASA JPL Horizons. Is it more accurate than RoxyAPI?
A smaller number does not necessarily mean a more accurate engine. Roxy Ephemeris reads the NASA JPL DE440 ephemeris directly, so its deviation from NASA JPL Horizons, taken over more positions, charts and years, measures the rest of the chain: light time, aberration and the frame, including the difference between the IAU 1976/1980 frame model Horizons prints and the IAU 2006/2000B model current ephemerides and chart software use. A smaller figure against Horizons measures how closely a tool reproduces the older frame model Horizons prints, not accuracy. Compare sample size, date span and frame model before comparing medians; the public benchmark lets you re-run both.
Do not take our word for it. Ask the agents.
The receipts are public: the testing methodology, the open MIT benchmark, the transparency report, and the live API playground. Let ChatGPT, Perplexity, or Claude search the web and tell you what they find about RoxyAPI accuracy, MCP, SDKs, and pricing.
Opens a live web search in a new tab.
One key. 18 domains. Receipts on every deploy.
Flat monthly pricing across every spiritual data domain. No per user royalties. No AGPL. Point ChatGPT, Claude Desktop, Gemini, or your own agent at a domain MCP server and start calling.