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.

One arcsecond is one thirty-six-hundredth of a degree, an extremely fine angular measure. Arcsecond-level means our planetary longitudes typically agree with NASA JPL Horizons to within roughly 1.5 arcseconds, about 0.0004 degrees, with a worst case near 16.6 arcseconds. That is far finer than the human eye can resolve and about 0.001 percent of a zodiac sign, well inside the tolerance any astrologer or application layer could act on.

Arcsecond-level 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 across Vedic and KP reference sources, which can drift a few arcseconds between sources without indicating any calculation error. The public 210 point benchmark records a 1.5 arcsecond (0.0004 degree) median and 16.6 arcsecond (0.0046 degree) maximum against JPL Horizons DE441.

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 and KP astrology against established sidereal almanac and KP sub-lord references, moon phases against published astronomical tables, numerology against the 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 (180 arcseconds) 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 an established KP sub-lord reference. Observed agreement across the public 210 point benchmark is well inside these guard rails: median 1.5 arcseconds (0.0004 degrees), maximum 16.6 arcseconds (0.0046 degrees).

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.

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

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.

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 sub period boundaries are computed as exact proportional arcs. Gold standard tests verify transition dates within 2 days of an established Vedic almanac 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 an established Vedic almanac 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 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.

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

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.

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 arcsecond-level 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.