Why Almost Every Astrology API Is the Same Engine (and What That Means for You)

If you are evaluating astrology APIs, the most useful question you can ask is not "which one has the most endpoints" or "which is cheapest." It is: what ephemeris does it actually run on? Because once you trace the data flow back to the source of the planetary positions, a surprising thing happens — most of the vendors collapse into the same underlying engine. The differentiation you are paying for is largely the front-end: the REST shape, the docs, the pricing tiers, the wrapper logic. The astronomy is shared.

This is not a knock on those products. The shared engine is excellent. But it has consequences — particularly licensing consequences — that matter a lot if you are embedding astrology into a commercial product. This article maps the landscape honestly, names which APIs own their engine and which rent it, and explains what the concentration means for you as a developer or a buyer.

The short answer: it's almost always the Swiss Ephemeris

The Swiss Ephemeris, maintained by Astrodienst, is the reference-grade astronomical library that the overwhelming majority of astrology software is built on. It reproduces NASA JPL's DE ephemerides to roughly one milliarcsecond — sub-arcsecond on everything, for any practical purpose effectively perfect. It is, correctly, the gold standard. If you have used astrology software in the last twenty years, you have almost certainly consumed Swiss Ephemeris output, possibly several layers removed.

Here is a representative — not exhaustive — list of widely used astrology APIs and libraries that wrap the Swiss Ephemeris and inherit its behavior and its license:

• Prokerala
• AstrologyAPI.com
• DivineAPI
• FreeAstrologyAPI
• Kerykeion (Python)
• flatlib (Python)
• immanuel (Python)
• VedAstro

This is the concentration risk. When eight-plus distinct commercial and open-source projects all derive their planetary positions from one C library, the "competition" in the category is mostly competition over packaging. That is fine — until the license enters the conversation.

The licensing fork that most buyers miss

The Swiss Ephemeris is dual-licensed: AGPL-3.0 or a paid commercial license. That "or" is the entire game.

Under the AGPL, §13 (the network-use clause) is the critical part. If you run a networked service — a SaaS, a web app, an API — that links the Swiss Ephemeris, the AGPL obligates you to offer the complete corresponding source of your service to your remote users. Not just the ephemeris; the application that links it. For a closed-source commercial product, that is usually a non-starter.

The legitimate escape hatch is the commercial license from Astrodienst. To be fair and accurate: it is a modest one-time fee with 99-year validity — not a recurring tax, and not "a fortune." Plenty of serious companies buy it and move on. So the honest framing is not "Swiss Ephemeris is expensive." It is this: if a vendor wraps the Swiss Ephemeris, then either (a) their service source is AGPL-disclosable to you and their users, or (b) they hold a commercial license and you are downstream of that one upstream legal dependency. Either way, the copyleft obligation lives somewhere in the stack you are building on.

The two engines that aren't the Swiss Ephemeris

There are exactly two players in this space that we are aware of who built and own their own ephemeris engine rather than wrapping the Swiss one:

RoxyAPI — Roxy Ephemeris (MIT)

RoxyAPI ships its own engine, validated against JPL Horizons, under the permissive MIT license. Credit where due: this is a real, independent engine and a genuinely different posture from the wrap-and-resell crowd. If you are comparing against RoxyAPI specifically, the "owns its engine" line is not a differentiator — both of us cleared that bar. The comparison there moves to the full stack, which we cover below.

XALEN — Vedika's pure-Rust engine (Apache-2.0)

XALEN is the ephemeris engine behind Vedika. It is written from scratch in pure Rust and released under Apache-2.0. The astronomical method stack is conventional and inspectable:

• Planets: VSOP87A analytic theory
• Moon: truncated ELP2000-82
• Reductions: Meeus algorithms, IAU 2006 precession, IAU 2000B nutation
• Optional high-precision path: a JPL DE440 SPK kernel reader

Engineering properties that matter for production: a zero-unsafe core, thread-safe by construction, compiles to wasm32 (so it runs in the browser and at the edge), and computes a full chart in roughly 336 µs.

It is genuinely published and installable today — this is verifiable in 30 seconds, which is the whole point:

cargo add xalen-ephem
pip install xalen
npm i @xalen/wasm

The published surface, all at v0.6.0, includes 15 crates on crates.io (xalen-ephem, -coords, -houses, -vedic, -western, -time, -ayanamsa, -stars, -chart, -chinese, -world, -lalkitab, -iching, -numerology, -ffi), the @xalen/wasm and @vedika-io/* npm packages (SDK, MCP server with 36 tools, CLI, React), and xalen plus vedika-sdk on PyPI. The source lives at github.com/vedika-io/xalen-ephemeris under Apache-2.0.

Accuracy: the honest framing

This is where category marketing usually goes off the rails, so let us be precise and resist the temptation to overclaim.

The Swiss Ephemeris reproduces JPL to about one milliarcsecond, and it is the reference. XALEN does not beat it, and we will not say it does. What XALEN does is match JPL-class parity for the classical planets — sub-arcsecond agreement against NASA JPL DE440 — while the analytic Moon model is wider (arcsecond-class rather than milliarcsecond-class). If you need milliarcsecond Moon and outer planets, you load the DE440 kernel via the optional reader and you are reading JPL directly.

Here are the real numbers. They are reproducible — clone the repo and run cargo run -p xalen-validation — which is the only kind of accuracy claim worth printing. Mean error vs NASA JPL DE440 over 1900–2050:

A 20,000-chart sweep across the 1900–2050 grid produced zero charts exceeding 0.1° of error. For context, 0.1° is six arcminutes — far below the threshold at which any chart factor (sign, nakshatra, house, dasha boundary) would change. Every planet is sub-arcsecond; the Moon is arcsecond-class. That is "matches the reference for practical astrology," not "more accurate than the reference." Both statements being true at once is the honest position, and it is the one a skeptical engineer can confirm for themselves.

So what does owning the engine actually buy you?

Three concrete things, in order of how much they tend to matter:

1. Permissive licensing. Apache-2.0 means you can embed the engine in a closed-source product, ship a white-label deployment, or run fully on-prem with zero source-disclosure obligation and no upstream copyleft dependency to manage. For a B2B integrator, this is frequently the deciding factor — legal review passes without a Swiss commercial-license procurement step.
2. No upstream legal dependency. Your astronomy is not gated on a third party's licensing terms changing. The dependency graph for the core math is yours.
3. Edge and embedded reach. A pure-Rust, zero-unsafe, wasm32-target core runs where a C library linked into a server process does not — in the browser, in a serverless edge function, inside a mobile build via FFI.

Beyond the ephemeris: the full stack

Here is the part that often gets lost: the Swiss Ephemeris (and any raw ephemeris) gives you astronomy, not astrology. It returns planetary positions, house cusps, and angles. It does not compute yogas, doshas, dashas, or compatibility scores. Every vendor builds that interpretive layer themselves, and that layer is where real product differentiation lives.

For Vedika specifically, the stack on top of XALEN is:

• 25 systems / 704 operations (~250 available in the public sandbox), spanning Vedic, Western, KP, Chinese, numerology, and more
• 104–131 computed yogas, doshas, Vimshottari plus conditional dashas, 36-guna matching, Lal Kitab, KP, 60 divisional charts, 50 ayanamsas, 23 house systems
• A native RAG-grounded conversational LLM endpoint (POST /api/v1/astrology/query) — grounded in computed chart facts, not canned text
• Native voice (speech-to-text → reasoning → text-to-speech) in 30 languages; 30 languages platform-wide
• An MCP server (36 tools) so AI agents can call the astrology stack directly
• Pricing from $12/month

Against a fellow engine-owner like RoxyAPI, this is where the comparison actually resolves: not on "who owns their ephemeris" — we both do — but on breadth of interpretive systems, the conversational and voice layers, multilingual coverage, and agent-native tooling.

How to evaluate any astrology API in five minutes

A practical checklist, vendor-neutral:

• Ask what ephemeris it uses. If the answer is "Swiss Ephemeris" (directly or via a wrapper), you are in the concentrated 90%. That is not bad — just know it.
• Trace the license. If you ship closed-source, find out whether the engine's license forces disclosure, and whether the vendor holds a commercial license. Permissive (Apache/MIT) removes the question entirely.
• Demand a reproducible accuracy claim. "Sub-arcsecond" with no method and no command behind it is marketing. A run-it-yourself validation command is engineering.
• Separate astronomy from astrology. Count the interpretive systems and computed factors — that is the part the ephemeris does not give anyone for free.
• Check deployment reach. Need edge, browser, or on-prem? A wasm32/permissive engine changes what is possible.

Bottom line

Most astrology APIs are honest, capable products built on one outstanding shared library — the Swiss Ephemeris — and they compete on packaging while inheriting its AGPL/commercial licensing fork. Two players, RoxyAPI and Vedika's XALEN, own their engines outright. XALEN's specific contribution is a pure-Rust, Apache-2.0, edge-deployable engine that matches JPL-class parity for the classical planets (with reproducible numbers and a DE440 path for milliarcsecond work when you need it), wrapped in a 25-system interpretive stack with conversational and voice layers on top.

If you want to verify all of this rather than take our word for it: the crates, npm packages, and PyPI modules are live (cargo add xalen-ephem / pip install xalen / npm i @xalen/wasm), the validation command is runnable from the repo, and you can exercise the full API in the free sandbox. Start at vedika.io — the docs and sandbox are linked from the homepage.