API health and supported options reference
Updated
The health and options endpoints of API for Astrology (apiforastrology.com) report on the Astrology API itself. GET /v1/health is a free uptime check that needs no API key. GET /v1/meta lists the ayanamsas (zodiac starting points), the languages, the divisional charts and the date range. The group has 2 endpoints.
Point your uptime monitor at GET /v1/health. Build your app's menus from GET /v1/meta, such as the ayanamsa choices or the languages. Then the menus always match what the API supports. The ayanamsa guide explains each ayanamsa choice, and the conventions explain the date range.
Service health, and what the API supports: ayanamsas, the house system, divisional charts and the date range. No birth data needed.
2 endpoints. Paths are relative to https://apiforastrology.com/api/astrology. Send your API key in the Authorization: Bearer header (see authentication). No key yet? Get a key. To send test requests from the browser, open the interactive reference.
Which health or options endpoint to call
| What you need | Endpoint | Cost |
|---|---|---|
| An uptime check for your monitor. No key needed | GET /v1/health | Free |
| The options and limits the API supports, to fill your menus | GET /v1/meta | 1 call |
Health check
GET /v1/health
Returns {"status": "ok"} while the service is running. Use it for uptime checks and load balancer probes. This is the only endpoint that needs no API key.
Cost: Free: does not count toward your monthly calls.
Required inputs
None.
Main response fields
status(string)
curl "https://apiforastrology.com/api/astrology/v1/health" \
-H "Authorization: Bearer $ASTROLOGY_API_KEY"{
"status": "ok"
}Example from a real call. Long lists and texts are shortened.
Parameters, schemas and a test request in the interactive reference.
Supported options and limits
GET /v1/meta
Lists what the API supports. That covers ayanamsas, node types and how time zones are handled. It also covers the languages and lengths for reading text, and the languages for names. Then the house system, all 16 divisional charts with what each is used for, the supported date range, the accuracy statement, and two measured checks: against NASA JPL Horizons and, from a clock time, against Swiss Ephemeris. Use it to build menus and input checks instead of hard-coding these lists. No birth data needed.
Cost: Each successful request counts as 1 call toward your monthly calls.
Required inputs
None.
Optional inputs (1), with their defaults
| Name | In | What it does |
|---|---|---|
| lang | query | Language for the names in the response, such as planets, signs, nakshatras (lunar mansions), tithis (lunar days), months and festivals. The default is en (English); GET /v1/meta lists the others. Each translated value comes with its English original in a matching <field>_en field; use the English value as a key in your code. Codes (such as result or kaal) and object keys always stay in English. Any name not yet translated stays in English and is listed in localization.untranslated. |
Main response fields
ayanamsas(array of strings)nodes(array of strings)timezones(object): holds accepts, daylight_saving, zones, database, ambiguous_times.prose(object): holds languages, details, note.names(object): holds languages, note.house_system(string)vargas(array of objects): each item holds varga, divisions, name, signifies.date_range(object): holds from, to, limited_by.ephemeris(string)accuracy(string)accuracy_engine(object): holds reference, compared, bodies, positions, from, to, step_days, planets_arcsec, moon_arcsec, moon_median_arcsec, checked_on.accuracy_clock(object): holds reference, compared, charts, from, to, planets_arcsec, moon_arcsec, moon_median_arcsec, true_node_arcsec, ascendant_arcsec, checked_on.
curl "https://apiforastrology.com/api/astrology/v1/meta" \
-H "Authorization: Bearer $ASTROLOGY_API_KEY"{
"ayanamsas": [
"lahiri",
"kp",
"raman"
],
"nodes": [
"true",
"mean"
],
"timezones": {
"accepts": [
"IANA time zone name, such as \"America/New_York\"",
"fixed offset from UTC in hours, such as -5 or 5.5"
],
"daylight_saving": "applied. A zone name is looked up in the time zone database for the exact birth moment, so daylight saving time, wartime clock changes and past changes to standard time are all included.",
"zones": 598,
"database": "tzdata 2026.4",
"ambiguous_times": "a local time that happens twice (when clocks go back) or never (when clocks go forward) is rejected, not guessed. Send `timezone_fold` or a numeric offset to say which one you mean."
},
"prose": {
"languages": [
"en",
"hi"
],
"details": [
"standard",
"expanded"
],
"note": "Language and length are set separately, for example `?lang=hi&detail=expanded`. Each text block reports the language and length it was actually served in. These can differ from what you asked for when a passage is not written yet in that…"
},
"names": {
"languages": [
"en",
"hi"
],
"note": "Every `/v1/` endpoint takes `?lang` for the names it returns, such as planets, signs, nakshatras, lunar days, months and festivals. Each translated value comes with its English original in a matching `<field>_en` field; use the English…"
},
"house_system": "whole sign",
"vargas": [
{
"varga": "D1",
"divisions": 1,
"name": "Rasi",
"signifies": "the body and life as a whole"
},
{
"varga": "D2",
"divisions": 2,
"name": "Hora",
"signifies": "wealth"
},
{
"varga": "D3",
"divisions": 3,
"name": "Drekkana",
"signifies": "siblings and courage"
}
],
"date_range": {
"from": "1850-01-01",
"to": "2149-12-31",
"limited_by": "Dates from 1850 to 2149, the range covered by the NASA JPL planetary data (DE440s) the API uses."
},
"ephemeris": "JPL DE440s (NASA/JPL)",
"accuracy": "checked against Swiss Ephemeris: the ayanamsa agrees within 0.001 arcseconds on 8 dates from 1900 to 2100. We also checked 12 charts. On the 11 dated from 1855 to 2026, the Sun, Moon, Mars, Mercury, Jupiter, Venus and Saturn agree within…",
"accuracy_engine": {
"reference": "NASA JPL Horizons",
"compared": "geocentric positions (astrometric, ICRF) at the same moment",
"bodies": [
"Sun",
"Moon",
"Mercury"
],
"positions": 25571,
"from": "1850-01-01",
"to": "2149-12-31",
"step_days": 30,
"planets_arcsec": 0.001,
"moon_arcsec": 0.011,
"moon_median_arcsec": 0.0025,
"checked_on": "2026-11-02"
},
"accuracy_clock": {
"reference": "Swiss Ephemeris 2.10.03",
"compared": "sidereal positions from a birth clock time",
"charts": 2000,
"from": "1850",
"to": "2026",
"planets_arcsec": 0.06,
"moon_arcsec": 0.41,
"moon_median_arcsec": 0.013,
"true_node_arcsec": 0.12,
"ascendant_arcsec": 0.004,
"checked_on": "2026-11-02"
}
}Example from a real call. Long lists and texts are shortened.
Parameters, schemas and a test request in the interactive reference.
How we check the numbers
Every answer here starts from planet positions worked out from NASA JPL planet data (DE440). We test them against NASA JPL Horizons, NASA's planet position service. On 25,571 positions from 1850 to 2149, the Sun and planets agree within 0.001 arc seconds. The Moon agrees within 0.011. On 2,000 random birth charts, the rising sign agrees with Swiss Ephemeris within 0.004 arc seconds. An arc second is 1/3,600 of a degree. A practicing astrologer reviews the rules behind these answers. See how we test accuracy.
Related pages
- Guides: Quickstart, Conventions, Errors, Changelog.