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 sub-arcminute accuracy. No AGPL restrictions. No copyleft licensing. No obligation to open-source your application.

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.

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.

Every domain is verified against authoritative sources: planetary positions against NASA JPL Horizons DE441 (ssd.jpl.nasa.gov/horizons), Vedic astrology against DrikPanchang (drikpanchang.com), KP astrology against onlinejyotish.com, moon phases against timeanddate.com, numerology against Pythagorean standard, I-Ching against the King Wen traditional sequence, crystals against GIA (Gemological Institute of America). The public MIT-licensed benchmark at github.com/RoxyAPI/astrology-api-benchmark publishes a runnable Python suite that re-validates 210 planet positions across 21 charts against JPL Horizons. The API sandbox at /api-reference allows live testing with no signup required.

Planetary longitudes are verified within 0.05 degrees (3 arcminutes) of NASA JPL Horizons DE441. The Moon uses a 0.2 degree band and Chiron uses 2 degrees, both looser by design because the Moon moves roughly 13 degrees per day and Chiron is a perturbed Keplerian orbit. Ascendant, Midheaven, and house cusps are verified within 0.5 degrees. Nakshatras and zodiac signs must match exactly. KP sub-lord assignments are verified against onlinejyotish.com. Observed agreement across the public 210 point benchmark is well inside these guard rails: median 0.27 arcmin, maximum 0.54 arcmin.

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, pure analytical computation with zero file I/O, and cloud-native deployment with no compilation step.

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.

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.

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.

Roxy Ephemeris uses analytical planetary theory, verified at runtime against NASA JPL Horizons. JPL Horizons itself is backed by the DE441 numerical ephemeris, and our outputs are cross-checked against Horizons at the same instants and coordinates. No binary ephemeris files are shipped, loaded, or read at request time.

One arcminute is one sixtieth of a degree, roughly the width of a US penny viewed from 230 feet away. Sub-arcminute means our planetary longitudes typically agree with NASA JPL Horizons to better than 0.0167 degrees. This is well inside the tolerance any astrologer or application layer could act on.

Sub-arcminute is the observed agreement against NASA JPL Horizons. The 0.05 degree planet tolerance and 0.2 degree Moon tolerance are regression guard rails, not descriptions of live accuracy. They also absorb small definitional differences between ayanamsha implementations at DrikPanchang and onlinejyotish.com, which can drift a few arcseconds between sources without indicating any calculation error. The public 210 point benchmark records a 0.27 arcmin median and 0.54 arcmin maximum against JPL Horizons DE441.

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.

Lahiri is the Indian government standard sidereal offset used by most Vedic software and DrikPanchang. 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 DrikPanchang for Lahiri and onlinejyotish.com for KP Newcomb.

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 onlinejyotish.com.

Vimshottari Dasha uses the solar year (365.25 days) for the partial first Mahadasha balance and calendar years for subsequent full periods, matching DrikPanchang Kundli across decades. The starting mahadasha is determined from the Moon nakshatra lord at birth, and sub period boundaries are computed as exact proportional arcs. Gold standard tests verify transition dates within 2 days of DrikPanchang for two birth epochs (Rohtak 1984, Mumbai 2026).

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 DrikPanchang exactly across every divisional chart in the gold standard suite.

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.

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.

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.

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 210 reference points across 21 charts (8 named celebrities and 13 synthetic edge cases including DST transitions, the Samoa 2011 calendar skip, and high latitude locations) with a single python3 benchmark.py command.

Call the RoxyAPI Vedic birth chart endpoint with Lahiri ayanamsha, the same birth date, time, and geographic coordinates. Then generate the same chart on drikpanchang.com 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.

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.

Every request runs in a stateless, in-process computation with no shared ephemeris files 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.

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. Claude Desktop, Cursor, Claude Code, and any MCP compatible client can consume the tool list directly. No local process or Docker required. The JSON response shape is stable, typed via OpenAPI, and documented at /api-reference, so agent tool calls stay deterministic across deployments.

Yes. Every endpoint is defined with a versioned OpenAPI schema, published at /api/v2/{slug}/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. Agents that bind tool calls to field paths continue to work without code changes across deployments.

Yes. Our analytical planetary theory is valid for historical charts from the early modern era through multi-decade future projections, and is continuously cross-checked against NASA JPL Horizons at test time. Natal charts for historical figures, solar returns decades into the future, and long range Vimshottari mahadasha transitions stay within the same sub-arcminute accuracy envelope as present day charts.

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.

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.