Astrology API: Why Two APIs Give Two Charts, Measured
Two astrology APIs return different charts for the same birth details because of 3 inputs, not because of the astronomy: which ayanamsa they apply, how they turn a local clock time into a universal instant, and which house system they use. The planetary positions themselves agree: we compared Swiss Ephemeris with NASA JPL's DE440 at 3,000 moments between 1950 and 2030, and the Moon never differed by more than 0.41 arcseconds. Choose an API that lets you set the ayanamsa and house system explicitly, resolve historical time zones yourself, and check what its ephemeris licence requires of you. Everything else is detail hanging off those 3.
The usual comparison between astrology APIs is price per call and the number of endpoints. Both matter less than what the API does with the birth time you send it. In our test of 20,000 random Indian birth moments, switching from the Lahiri to the Raman ayanamsa moved the Moon into a different nakshatra in 10.9 per cent of charts, and a birth time off by 1 hour changed the ascendant sign in 50.3 per cent. The failure is ordinary: a user born in Kolkata in 1943 sees the wrong ascendant, because the app sent +05:30 when India was on +06:30 that year.
Here is a real example, computed for the moment this post goes live. New Delhi, 10 October 2026, 00:00 IST. Under the Lahiri ayanamsa with whole sign houses, the ascendant is Gemini at 29.34 degrees. Under the Raman ayanamsa, the same instant gives Cancer at 0.78 degrees. Under Lahiri again, a birth 4 minutes later also gives Cancer.
Nothing in that example is an error. Every number came from the same ephemeris, the same code and the same coordinates. The difference is a convention that one API applies by default and another lets you choose, and a 4 minute window that a rounded birth time can easily cross.
The outputs most sensitive to these inputs are the ones users notice first. The ascendant decides every house in a Vedic chart. The Moon's nakshatra decides where the Vimshottari dasha sequence starts, which moves every predicted period that follows. Planet positions in signs rarely change, which is why 2 charts can look almost identical and still disagree on the parts a user is most likely to check.
Planetary positions are a solved problem. Swiss Ephemeris, which Astrodienst says has been based on NASA JPL's DE441 since May 2026, states that its compressed files reproduce JPL's ephemeris to 0.001 arcseconds. DE440 and DE441 were published by Ryan Park, William Folkner, James Williams and Dana Boggs in the Astronomical Journal in February 2021.
We checked it independently. We computed the apparent geocentric longitude of the Sun, Moon, Mars, Jupiter and Saturn at 3,000 random moments between 1950 and 2030, once with pyswisseph 2.10.3.2 and once with Skyfield 1.55 reading JPL's DE440s file. The largest difference was 0.41 arcseconds, for the Moon, and the median Moon difference was 0.013 arcseconds. For the Sun, Mars and Saturn the largest difference was 0.03 arcseconds or less.
0.41 arcseconds is about 1 second of time for the Moon. The Moon moves roughly half a degree an hour, so the worst disagreement we found between 2 independent ephemerides is smaller than the error in any recorded birth time. If an API vendor's main sales argument is ephemeris accuracy, they are selling the part that does not differ.
The exception is an engine that is not a JPL-derived ephemeris. One vendor we reviewed, FreeAstrologyAPI, states that it uses a proprietary in-house calculation engine rather than Swiss Ephemeris. That is not wrong in itself, but it is the one case where you should test planet positions directly before trusting them.
Vedic astrology uses sidereal positions, which means subtracting an ayanamsa from the tropical longitude. The ayanamsa is the angle between the 2 zodiacs, and there is no single agreed value. Swiss Ephemeris implements dozens. The 4 below, all offered by at least 1 of the vendors we reviewed, span 2.33 degrees.
Ayanamsa | Value on 6 Oct 2026 | Difference from Lahiri |
Fagan/Bradley | 25.114° | +0.883° |
Lahiri | 24.231° | 0 |
Krishnamurti (KP) | 24.134° | −0.097° |
Raman | 22.785° | −1.446° |
Lahiri is the default almost everywhere in India for a historical reason. Swiss Ephemeris documentation records that the Indian Calendar Reform Committee declared a Spica-based ayanamsa the Indian standard in 1955, with a value of 23°15'00" on 21 March 1956, and that it became the basis of the Indian Astronomical Ephemeris and the Rashtriya Panchang. Swiss Ephemeris's standard Lahiri follows the Indian Astronomical Ephemeris of 1985, which differs from the committee's original value by 1.1 arcseconds.
We measured what the choice does to real charts. Across 20,000 random birth moments between 1950 and 2030, at random locations across India, we computed each chart under Lahiri and under each alternative.
Raman instead of Lahiri changed the Moon's nakshatra in 10.9 per cent of charts, the Moon's sign in 4.4 per cent and the ascendant sign in 4.8 per cent. Fagan/Bradley changed the nakshatra in 7.0 per cent. Krishnamurti, only 5.8 arcminutes from Lahiri, changed it in 0.7 per cent: rare, but enough that a KP astrologer and a Lahiri astrologer will occasionally disagree on a dasha start date.
The fix is not choosing the right ayanamsa. It is storing the one you used. Every chart your system produces should record its ayanamsa next to the result, and your API should let users who follow a different tradition choose theirs. An API with no ayanamsa parameter has made that decision for every one of your users.
The Vimshottari dasha turns the Moon's exact position into dates. The nakshatra the Moon occupies at birth picks the first period's ruling planet, and how far the Moon has travelled through that nakshatra decides how much of the period is left. Each nakshatra spans 13°20', so a shift of 1.446 degrees, the gap between Lahiri and Raman in 2026, is about a ninth of a nakshatra.
We measured what that does to the first date a user sees. For the same 20,000 birth moments, we computed when the birth dasha ends under Lahiri and under each alternative, counting a year as 365.25 days. Where the birth dasha's ruling planet stayed the same, we measured how far the end date moved. dasha_shift.py reproduces it.
Change | Birth dasha ruler changes | End date moves, median | End date moves, 90th percentile |
Raman instead of Lahiri | 10.7% of charts | 634 days | 792 days |
Krishnamurti instead of Lahiri | 0.7% of charts | 43 days | 53 days |
Birth time 15 minutes later | 1.0% of charts | 58 days | 75 days |
Birth time 1 hour later | 3.9% of charts | 230 days | 300 days |
A user comparing 2 apps sees different years, not different degrees. Lahiri and Raman put the end of the birth dasha a median of 1.7 years apart, and in 1 chart in 10 they name a different ruling planet entirely. Every later period inherits the difference. That is why the ayanamsa belongs in your stored data, and why an API that silently changes its default would rewrite every timeline you have already shown.
The day count is a convention too. Vimshottari periods are defined in years, and the number of days an implementation counts as a year moves long-range dates on its own. We used 365.25. Pick 1, document it, and store it.
The birth time is the weakest input, and the time zone is the weakest part of the birth time. In our 20,000 charts, a 4 minute error changed the ascendant sign in 3.2 per cent, a 15 minute error in 12.4 per cent, and a 1 hour error in 50.3 per cent. The Moon's nakshatra changed in 4.0 per cent of charts at 1 hour. A wrong time zone is a 30 or 60 minute error applied silently.
Most astrology APIs make you send the offset. Of the vendors we reviewed, AstrologyAPI takes a tzone number such as 5.5 and documents that the caller must resolve the historical offset, with a separate endpoint to help. Prokerala takes an ISO 8601 date and time with an explicit offset. VedicAstroAPI takes a tz value in steps of 0.5 hours. FreeAstrologyAPI states that it does not apply daylight saving automatically. Divine API's developer documentation requires a numeric tzone, while one of its marketing pages says historical offsets are applied automatically.
A half-hour step cannot represent real offsets. Nepal is at +05:45 today. India's tz database history includes +05:21:10 and +05:53:20. An API that only accepts half hours forces a rounding error into those charts before any astronomy happens.
India's own history is less tidy than +05:30. The IANA tz database, release 2026e, records Asia/Kolkata at +06:30 from October 1941 to 15 May 1942 and again from September 1942 to 15 October 1945. Before 1906 it uses Madras railway time, +05:21:10, and its maintainers note that Calcutta and Bombay kept their own local times for civil use. They also write that "Shanks is our only (and dubious) source for the 1941-1945 data."
Resolve the offset from the tz database, on your side, with the local time and the place. This function does that and returns the ascendant. It runs as written with pyswisseph and the Swiss Ephemeris files:
from datetime import datetime
from zoneinfo import ZoneInfo
import swisseph as swe
SIGNS = "Aries Taurus Gemini Cancer Leo Virgo Libra Scorpio Sagittarius Capricorn Aquarius Pisces".split()
def lagna(local: str, tz: str, lat: float, lon: float, ayanamsa: int = swe.SIDM_LAHIRI):
t = datetime.fromisoformat(local).replace(tzinfo=ZoneInfo(tz)) # historical offset from tzdata
u = t.astimezone(ZoneInfo("UTC"))
jd = swe.julday(u.year, u.month, u.day, u.hour + u.minute / 60 + u.second / 3600)
swe.set_sid_mode(ayanamsa)
asc = swe.houses_ex(jd, lat, lon, b"W", swe.FLG_SIDEREAL)[1][0]
return SIGNS[int(asc // 30)], round(asc % 30, 2), str(t.utcoffset())For a birth in Kolkata at 10:00 on 1 March 1943, it returns Aries at 14.13 degrees with an offset of +06:30. The same clock reading sent with a hard-coded +05:30 gives Taurus at 1.46 degrees. Same person, same clock, different ascendant, and no error message anywhere.
We read each vendor's own pricing page and documentation on 6 October 2026. Prices are the entry paid plan as published, monthly, before tax. Some vendors count calls and some count credits, so volumes are not directly comparable.
Vendor | Entry paid plan | Ayanamsa choice | Time zone input | Ephemeris stated |
AstrologyAPI | ₹1,500, 50,000 requests (Indian Basic) | Lahiri default, KP, Raman, Yukteshwar, JN Bhasin, Fagan/Bradley | Numeric offset from client; helper endpoint | Not stated |
Prokerala | ₹999, 100,000 credits (Ruby, discounted from ₹1,999) | Lahiri, Raman, KP | ISO 8601 with offset from client | Not stated |
VedicAstroAPI | ₹1,499, 30,000 calls (Vedic Limited) | No parameter; responses show Lahiri | Numeric offset in 0.5 hour steps | Not stated |
FreeAstrologyAPI | ₹1,000, 50,000 a month (Vedic Mercury) | Lahiri or tropical | Client sends offset; no automatic daylight saving | In-house engine |
Divine API | $19, 100,000 (Vedic Sampoorna) | Lahiri seen; no parameter found | Docs require numeric offset | Swiss Ephemeris |
AstroAPI | €39.99, 150,000 requests (Basic) | Not stated | Not stated | JPL DE442 claimed |
Read the table for its gaps, not its prices. 3 of the 6 do not say which ephemeris they run, and 1 uses an in-house engine. 2 give you no ayanamsa choice we could find. Every one that documents time zone input in its developer docs expects you to supply the offset.
House systems vary as well. AstrologyAPI defaults to Placidus and offers whole sign among 6 options. Prokerala and VedicAstroAPI list 7 or 8 systems. Divine API defaults to Placidus. The North and South Indian chart formats give each house exactly 1 sign, which is whole sign houses, so a default of Placidus is another setting to send explicitly rather than accept.
Swiss Ephemeris is offered under 2 licences. Astrodienst publishes it under the GNU Affero General Public Licence, or under the Swiss Ephemeris Professional License for those who do not want the AGPL's terms. You choose before any public service using the software goes live. The Python binding, pyswisseph, is itself AGPL v3.
The AGPL reaches network services. Section 13 of the AGPL requires that users who interact with a modified program over a network can obtain its source. If your chart service links Swiss Ephemeris under the AGPL, plan on publishing that service's source or buying the professional licence.
The professional licence is cheap and has a condition API users should read. On 6 October 2026 Astrodienst's price page lists an unlimited professional licence at CHF 700, and its September 2026 contract makes it valid for 6 years. The same contract states that a licensee who provides API services to third parties must have each of those third parties buy their own Swiss Ephemeris licence, and must say so in its API documentation. If your vendor runs Swiss Ephemeris under the professional licence, ask whether that clause applies to you.
JPL's own ephemeris files are open to use. NASA's NAIF rules permit anyone to use the SPICE kernels, including commercial use without fees, and to redistribute unmodified kernels. Skyfield, which reads them, is MIT licensed. An engine built on Skyfield and DE440 avoids the AGPL question, at the cost of writing your own ayanamsa and house calculations.
A full chart takes 0.08 milliseconds to compute locally. In our test, 8 bodies plus the ascendant and house cusps, sidereal, took 0.081 milliseconds per chart with pyswisseph on a 2019 Intel laptop. That is about 12,000 charts a second on 1 core. The astronomy is not what an API saves you.
What an API saves you is everything around the astronomy. Divisional charts, dasha timelines, compatibility scoring, panchang, interpretation text, and the endpoints that turn numbers into screens. Those are real work, and a vendor that has built and maintained them for years is worth paying.
Buy when the endpoints are the product you need. If your app shows charts, compatibility and daily panchang, and you are not differentiating on calculation, buying is the cheaper route. Send explicit ayanamsa, house system and offset with every call, and store them with the result.
Build the core when the chart is your product. If users choose their own ayanamsa, if you serve historical charts, or if you need results that never change when a vendor updates its engine, own the calculation layer and buy or build the interpretation around it. Budget for the Swiss Ephemeris licence decision, a tz database update process, and a regression test set.
That is the shape of our Tvam build. For Tvam, a Vedic astrology app on iOS, Android and the web, 1 server-side calculation service resolves the birth event, computes longitudes under the selected ayanamsa, derives house cusps and produces the divisional charts, and all 3 surfaces read its output. The clients draw that 1 chart model as both a North Indian and a South Indian chart. The Tvam case study covers the dasha timeline and the notification queue built on top of it.
Many teams do both. Compute positions, ascendant and dasha dates in house, where correctness is testable, and call an API for content-heavy endpoints where it is not.
Store the input, not just the result. Keep the local date and time as the user entered it, the IANA zone name, the coordinates, the ayanamsa, the house system and the engine version. With those, you can recompute any chart exactly. Without them, a vendor change silently rewrites your users' charts.
Never store only a UTC instant. Converting at capture freezes whichever tz database rules were current that day. The tz database had 5 releases in 2026 by October, from 2026a to 2026e, and historical corrections do happen. Keep the local time and the zone, and convert when you compute.
Build a regression set that targets the edges. Include births in India between 1941 and 1945, before 1906, in Nepal, and charts whose ascendant or Moon sits within half a degree of a boundary, like our New Delhi example. Run them against every vendor or engine update and fail the release if any result moves.
Ask every vendor 5 questions before you integrate. Which ephemeris, and under which licence? Which ayanamsas, and can you set it per call? Which house systems, and what is the default? Do they resolve historical time zones, or do you? And what happens to existing charts when they update their engine? An answer of "we handle it" to the last 2 is not an answer.
The short version. The planets agree to under half an arcsecond between Swiss Ephemeris and NASA JPL, so that is not why 2 astrology APIs disagree. They disagree on the ayanamsa, which moves the Moon's nakshatra in about 1 chart in 9 between Lahiri and Raman, and on the birth instant, where a 1 hour time zone error changes the ascendant in half of all charts and most APIs leave the time zone to you. Send every convention explicitly, resolve time zones from the tz database yourself, read the licence your vendor's ephemeris carries, and store enough to recompute every chart exactly.
An astrology API is a web service that takes a birth date, time and place and returns calculated astrological data, such as planetary positions, the ascendant, houses, nakshatras, dasha periods and compatibility scores. Most use an astronomical ephemeris such as Swiss Ephemeris for the positions and add astrology-specific conventions, like the ayanamsa and house system, on top. Plans are usually priced by calls or credits per month.
Mainly because of the ayanamsa and the time zone, not the astronomy. In a test of 20,000 random Indian birth moments, using Raman instead of Lahiri changed the Moon's nakshatra in 10.9 per cent of charts, and a 1 hour time zone error changed the ascendant sign in 50.3 per cent. Planet positions from Swiss Ephemeris and NASA JPL's DE440 agreed to within 0.41 arcseconds.
Lahiri is the most common default for Vedic astrology in India, following the Indian Calendar Reform Committee's 1955 standard used by the Indian Astronomical Ephemeris and Rashtriya Panchang. The better answer is to let users choose and to store the ayanamsa with each chart. On 6 October 2026, Raman was 1.446 degrees from Lahiri, Krishnamurti 0.097 degrees and Fagan/Bradley 0.883 degrees.
Most do not. AstrologyAPI, Prokerala, VedicAstroAPI and FreeAstrologyAPI document that the caller supplies the UTC offset, and FreeAstrologyAPI states that daylight saving is not applied automatically. Resolve the historical offset yourself from the IANA tz database using the local time and the place, because India, for example, was on +06:30 for most of 1941 to 1945.
Yes, under one of 2 licences. Under the GNU AGPL, software that uses it over a network must make its source available to users. Alternatively, Astrodienst's Swiss Ephemeris Professional License cost CHF 700 for unlimited projects on 6 October 2026, valid for 6 years. Its contract requires licensees offering API services to third parties to have each third party buy its own licence.
Astrodienst states that Swiss Ephemeris is based on NASA JPL's DE441 since May 2026 and reproduces it to 0.001 arcseconds. In our own comparison at 3,000 moments between 1950 and 2030, pyswisseph and Skyfield with JPL's DE440s agreed to within 0.41 arcseconds for the Moon and 0.03 arcseconds or less for the Sun, Mars and Saturn.
Published entry plans on 6 October 2026 ranged from about ₹999 to ₹1,500 a month for 30,000 to 100,000 calls or credits at Indian vendors, $19 a month for 100,000 at Divine API, and €39.99 a month for 150,000 at AstroAPI. Computing a chart locally takes about 0.08 milliseconds, so the price pays for endpoints and interpretation rather than the calculation itself.
Vikas has around fifteen years of experience building software and now builds generative AI systems at Zyneto. His work covers retrieval augmented generation, agentic AI, knowledge graphs, AI memory, and the evaluation and guardrails that decide whether any of it is safe to put in front of customers. He has shipped enterprise copilots, document AI, chatbots and predictive analytics for e-commerce, fintech and marketing teams, and works day to day in Python, JavaScript and SQL. He follows multimodal models, business process automation and enterprise AI security closely, and mentors engineers moving into AI. He writes about architecture, inference cost and the failure modes that only show up at production scale.
Share your details and we will talk soon.
Be the first to access expert strategies, actionable tips, and the trends actually shaping the digital world. No fluff - just practical insights delivered straight to your inbox.
Dive into our blog and stay ahead of the curve with expert perspectives, future-ready trends, and tech tips written for decision-makers and doers alike.
