10 Questions to Ask an Astrology API Provider

Choose the astrology API that passes 10 tests with your own birth data. Do not choose on the home page or the length of the feature list. Most tests are a single API call. Run them on every vendor on your shortlist, before you sign anything. For the full checklist, see our guide to choosing a Vedic astrology API.

Below, each question shows how our own API answers it. Every number comes from a call we ran in October 2026, or from our public docs. Use the same tests on any vendor.

1. Does it match a trusted reference?

Every chart starts with planet positions. If those are wrong, every reading built on them is wrong too. So ask each vendor what they test against, and how close they get.

Our API takes its planet data from the JPL DE440s ephemeris, a table of planet positions published by NASA. We check our results against Swiss Ephemeris, a widely used standard in astrology software. The results are in arc seconds. One arc second is 1/3,600 of a degree.

The test: pick 5 births your team trusts. Run them through the vendor and through desktop software you already use. Compare each planet in arc seconds, not just by sign. A sign can match while the degree is off. Our full method is on the accuracy page.

2. Can you choose the ayanamsa?

Vedic charts depend on one setting. The ayanamsa is the gap in degrees between the Vedic zodiac and the Western one. Different schools use different values. If an API hides its choice, you cannot match the charts your users already have.

Our API defaults to Lahiri and also takes KP or Raman. We sent John Doe's birth (Aug 15, 1990, 10:30 AM, New York) 3 ways:

KP moved John's Moon by 5′49″, and Raman by 1°26′47″. His Moon stayed in the same nakshatra (birth star) all 3 times. A planet near an edge would not. Every answer names its setting in meta.ayanamsa, so your logs show which one ran.

The test: send one chart with each setting and check that the reply names it. Then send kundli matching with two different settings. Our API refuses that with a 422 and says why: "both charts must use the same ayanamsa; got kp and lahiri". Our post on Lahiri, KP and Raman explains which one to pick.

3. Which dates does it cover?

Old births and far-off forecasts both hit the edges. A family app may chart a grandparent born in 1920. A forecast screen may look 50 years ahead. So ask for the exact range, and ask what happens outside it.

Our API covers Jan 1, 1850, to Dec 31, 2149. That is the span of the NASA planet data it uses. A birth in 1850 worked. A birth in 1849 and one in 2150 each came back with status 422. Each reply named the year field and said: "The birth date must be between January 1, 1850 and December 31, 2149."

The test: send a date one year past each end. A good API refuses it clearly. A weak one returns a chart anyway, and you cannot tell how far to trust it.

4. Does it handle time zones and daylight saving?

A clock error moves the whole chart. The API must turn a local birth time into world time. That depends on the place, the date and the laws of that year.

Our API takes a time zone name such as America/New_York. It looks up the offset for that exact moment in the time zone database. It knows 598 zones, from tzdata 2026.4. These tests show why that matters:

The Mumbai case matters for apps with users in India and abroad. With a plain UTC+5:30, that 10:30 AM birth gets an ascendant (rising sign) of Aquarius 26°21′. With the zone name, it is Aquarius 7°37′. That is a gap of almost 19 degrees.

Some local times happen twice, when clocks go back. Our API does not guess. It returns a 422 and asks for timezone_fold, 0 for the first time or 1 for the second. Every reply shows the offset it used in meta.timezone.

The test: send the January 1974 New York birth. If the reply says UTC-5, the vendor ignores history.

5. How do you get from a city to coordinates?

Users type a city, but charts need numbers. An API needs latitude, longitude and a time zone. So ask whether the vendor searches places for you, or expects your app to do it.

Our API takes coordinates and a zone name, not a city name. Your app needs a place search that returns all three. Our free kundli tool has one, built on a list of populated places worldwide. Type "Springfield" and add the state, such as "springfield, illinois", to pick the right one.

The API is strict about the numbers it gets. It reads "40,7128", a latitude written with a comma, the same as 40.7128. John's Moon came back identical both ways. A latitude of 140 came back as a 422 that named the field: "latitude out of range: 140.0".

The test: send a comma decimal, then a latitude over 90. The first should work. The second should fail with the field named.

6. Are the errors clear?

Your developers and your support team read the error replies. A vague "Bad request" tells them nothing about what to fix. So break a request on purpose and read what comes back.

Every error from our API has the same shape. It holds a fixed code for your program, a plain message for people, and the field at fault when there is one. We sent only John's birth date, with no place, and got this:

{
  "error": {
    "code": "invalid_input",
    "message": "Field required",
    "field": "latitude"
  }
}

Each reply also carries an X-Request-Id header for support. A call without a key got a 401 with the code unauthorized. Its message showed both ways to send a key. The errors page lists every status code and when to retry.

The test: send a request with a missing field, a request with no key, and a made-up path. Check that each reply has a code your program can match.

7. What are the rate limits?

Limits decide how your app behaves on its busiest day. Ask how many calls you can make per minute, per key and per month. Then ask how the API tells you that you are close.

Our API sets a per-minute limit for each live key, and each key has its own count. Every reply that passes the key check has 3 headers: X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset. When you go over, you get a 429 with a code that names the limit you hit, and a Retry-After header. Test keys have their own small limits and are never billed. The authentication page lists the limits for each plan.

The test: make one call and read the 3 headers. If a vendor has no limit headers, your code has to guess when to slow down.

Want to run these tests in your own code? The quickstart takes you from a key to a first chart in a few steps. It uses the same John Doe birth as this post.

8. Are the docs good enough to start without help?

Check what a developer gets on day one. Ask for a machine-readable spec, copy-paste samples and a list of every change.

Our public spec lists 50 paths, all under /v1/. You can download it as an OpenAPI file or a Postman collection. Each call in the API reference has samples in curl, JavaScript, Python and PHP. They use John Doe in New York and Jane Doe in Chicago. A changelog lists each change.

The test: give a developer only the docs and one hour. Ask for a chart for their own birth. Note each question they had to ask the vendor.

9. Is the reading text good, and in your users' language?

If your product shows readings, the text is part of your product. Ask where it comes from, and whether the same chart always gets the same words.

Our readings come from a fixed library of text, chosen by stated rules. No AI writes them. We asked for John's personality reading twice, and both answers matched word for word. Each answer lists the chart facts it draws on, such as "Moon in the 9th house". The public rulebook explains every rule. Why rule IDs matter shows what that does for your support team.

You can set the language and the length. Add lang=hi for Hindi, or detail=expanded for longer text. John's opening text grew from 138 words to 287 words when expanded. In Hindi, the same reading has the title "जीवन फल: स्वभाव" (Life prediction: personality).

The test: request one reading twice and compare. Then ask for it in each language your users read. Show both to someone who reads that language every day.

To see what the reading endpoints return, open the readings feature page. To try a chart without writing code, use the free kundli tool.

10. What happens to your users' birth data?

A birth date, time and place is personal data. Your users trust you with it, so the vendor must earn that trust too. Ask 3 questions: what is stored, what goes to third parties, and how long account data is kept.

Our security page gives the answers. Request bodies are not stored, by the gateway or by the calculation service. No request data goes to an AI provider. API keys are stored only as hashes. For support, each call keeps a short record of time, endpoint, status and request ID, with no birth details. When you ask us to close an account, we delete its data within 30 days. The page also says to send birth details in a POST body, since web addresses can end up in server logs.

The test: find these 3 answers in writing, on a public page. Then check the status page to see how the vendor reports problems.

Run all 10 tests on every vendor on your shortlist. If you also weigh a free plan against a paid one, read free vs paid astrology APIs. The vendor that passes with your own births is the one to build on.