Changelog what is new

2026-08-22 · Credit prices were printed wrong on several pages

The “Credits” tables in the docs named one number while another was charged. No price changed: the printed side was the wrong one. The real cost has always been in X-Credits-Used on every response and on the per-endpoint cost page, which is built straight from the cost table.

Where it costs more than we printed. This is the side that hits a budget:

The other direction exists too: Lal Kitab and KP doshas, the Jaimini yogas and part of the dashas cost 10, not the 20-100 that was printed.

What to do with your code. Recheck your credit budget if you planned it from these pages, and compare it against X-Credits-Used in your own logs. No call has to change.

Eighteen paths in those same tables have never existed. If your code holds any of them it returns 404 today and always has: every /v1/vedic/doshas/jaimini/*, /v1/vedic/doshas/all, /v1/vedic/muhurat/engagement, /griha-pravesh, /court-case, /v1/vedic/yogas/jaimini/atmakaraka, /badhaka. Three were a misspelling and are corrected: /v1/vedic/doshas/kp/mangal is kp/manglik, /v1/vedic/doshas/lal-kitab/kaal-sarp is lal-kitab/kalsarpa, /v1/vedic/panchang/nakshatra is panchang/nakshatra-of-day.

Vargas never took levels. The page promised a single /v1/vedic/vargas call with an array of levels; no such path exists. Each divisional chart is its own path, /v1/vedic/varga/D9 and the rest, at 20 credits per chart.

Every figure in the docs is now checked against the cost table mechanically, on every commit.

2026-08-21 · Symbolic directions: the arc key is validated, solar arc computes

POST /v1/symbolic-directions takes a key with three values: one_degree (the default, 1° per year), naibod (59’08.3” per year) and solar_arc (the arc of the progressed Sun). The parameter was missing from the schema and reached the calculation as a raw string, so every value except naibod returned null for all longitudes, cusps, the ascendant and the arc itself, all under a 200.

What to do with your code. If you were sending key: "solar_arc" or key: "one_degree" and getting null, you now get numbers: change nothing, the response simply became meaningful. If you were sending any other value, you now get a 400 with INVALID_INPUT instead of a silent null. The response gained a key field echoing the key that was applied.

solar_arc is the distance travelled by the progressed Sun, day for a year, so for a May birth it trails a degree per year: 34.51° against 36.00° over 36 years. Converse directions (converse: true) reverse the sign of the arc once.

2026-08-17 · Planetary hours and sun times fixed for half the timezones

POST /v1/planetary-hours and POST /v1/sun-times returned wrong values wherever the local day does not line up with the UT day. The sunrise hour was read inside the UT day and the offset added without wrapping, so Seoul came back with riseHour 29.81 and Los Angeles with setHour -4.36. The length of a day hour is (setHour - riseHour) / 12, so it came out negative and the table of 24 hours ran backwards in time.

Who this hit. All of East Asia and Oceania, Delhi near the solstice, both American evenings. Kyiv and Europe were correct before and after.

What to do with your code. Nothing to change, the contract is the same. But if you cached /planetary-hours or /sun-times responses for those regions, fetch them again: the stored value is wrong.

Verified against api.sunrise-sunset.org for Seoul, Tokyo, Los Angeles and Auckland: 1-2 minutes apart, systematic, and present before the fix as well.

Alongside it: tzOffset in a request body is now refused with 400 INVALID_FIELD and a hint. It used to be ignored in silence, the offset defaulted to zero, and the chart was computed for UTC with nothing to show for it. The field is still timezoneOffset.

2026-08-14 · Astrocartography: life categories and line interpretations

Three new endpoints turn /v1/acg geometry into an answer about a place. GET /v1/acg/categories returns a taxonomy of 19 life areas (career, love, money, health, home, learning, power, travel and more): each names its planet-and-angle lines with a weight of 1-3 and a polarity. Free, cache it on your side.

POST /v1/acg/by-category returns the lines for one area, ranked by weight, and when you pass a point, by proximity to it as well (strength = weight × proximity, plus distanceDeg). Tier 3. POST /v1/acg/line-report returns one line in full: geometry, every area it touches, and the interpretation text. Tier 2. Geometry comes back as segments, an array of polylines: a rising or setting curve is several disjoint pieces and all of them are returned.

Text is served from a curated knowledge base in 11 languages (language, falling back en → uk, with the language actually served reported in lang) rather than from a language model, so responses are deterministic. Challenging lines are returned alongside supportive ones; filter with polarity if you only want one kind. Details: Astrocartography interpretations.

Alongside this, the reference was corrected: the descriptions for /parans, /local-space, /solar-acg, /acg-zones and /zenith disagreed with the actual responses. The endpoints themselves are unchanged; only their documentation was.

2026-08-13 · POST /v1/reports/relocation, up to five places in one PDF

What to do with your code. Nothing, unless you were assembling a relocation document yourself. If you were, by stitching /v1/relocation together with /v1/acg-zones per city, that is now one call returning a finished PDF, or HTML with ?format=html. Tier 7, 5000 credits.

The body takes chart, a locations array of one to five entries each carrying coordinates, and optional categories, orbKm, language and whitelabel. Coordinates are required per place and are never defaulted to zero: a report cast at 0N 0E is a confident document about the Gulf of Guinea, and unlike a wrong JSON field a PDF is kept.

Per place the document gives the relocated ascendant and midheaven with a signed shift from birth, the list of planets that changed house (which is the substance of relocation, diffed rather than left as two tables to compare), every astrocartography line running within 300 km together with its interpretation text, and scores across the areas of life. With more than one place it opens on a side-by-side comparison.

Deliberately no AI narrative and no chart wheel. A wheel of the relocated chart shows the same planets in a rotated frame and reads as a second chart, which is the misconception the opening paragraph exists to correct; a narrative about a place would be advice on where to live.

2026-08-12 · Astrocartography horizon lines are fixed, remove the workaround

What to do with your code. If the entry below made you swap ASC and DSC on your side, remove that workaround or you will be reading the wrong half again. If you read the knownDefect field, it is gone from the responses of /v1/acg, /v1/acg-zones, /v1/acg/by-category, /v1/acg/line-report, /v1/parans and /v1/solar-acg. If you never got round to changing anything, there is nothing to do.

The coordinates moved, not just the labels. The old formula solved the horizon curve through ecliptic longitude and ignored the body’s ecliptic latitude, so the line drifted by roughly 103 km per degree of that latitude. Zero for the Sun and the nodes, hundreds of kilometres for the Moon, and over 1500 km for a body sitting high above the ecliptic. Both halves are now solved from the horizon equation in equatorial coordinates, the same way MC and IC always were.

The practical consequence: cached maps and stored line coordinates are worth rebuilding, or they will disagree with new responses. Parans (/v1/parans) moved with the lines. POST /v1/acg/best-places and POST /v1/parans/star did not change: they computed their own geometry from right ascension and declination from the start, and disagreeing with them is what exposed the bug.

The check now quoted on the accuracy page: take every point of every horizon curve and compute the body’s altitude there. Across 8419 points the largest deviation is zero.

2026-08-12 · ASC and DSC are swapped on astrocartography horizon lines

What to do with your code. If you distinguish ASC from DSC in the responses of the astrocartography endpoints, exchange them on your side: what we label ASC is where the body sets, and DSC is where it rises. Nothing needs recalculating, because it is the labels that are swapped and not the geometry. If you only use MC and IC, or never branch on the line type, there is nothing to do.

Affected: /v1/acg, /v1/acg-zones, /v1/acg/by-category, /v1/acg/line-report, /v1/parans and /v1/solar-acg. From today each of them returns a knownDefect field in the response body, carrying the stable id acg-horizon-labels-inverted, a description and the workaround. The field sits inside data rather than beside it, so it survives the envelope unwrapping our SDKs perform. It disappears when the defect does, so do not depend on it being there permanently.

MC and IC are correct: they are computed from right ascension separately. POST /v1/acg/best-places is also correct, computing its own geometry from hour angle and declination. Where best-places and /acg/by-category disagree on a horizon line, best-places is right.

One thing worth calling out separately: the interpretation text in /acg/by-category and /acg/line-report is selected by the (planet, angle) pair, so it describes the opposite half of the curve along with the label.

Found on 2026-08-05 while cross-checking two of our own endpoints against each other. The fix belongs to the shared calculation core and is in preparation; this entry will be updated when it lands.

2026-08-10 · @astroway/sdk 1.5.1, the quickstart example runs

What to do with your code. Nothing, unless you copied the quickstart out of the README. If you did, fix it: chart.angles.asc does not exist.

The /chart response has no angles key. The ascendant is chart.houses.ascendant, an ecliptic longitude in degrees rather than a sign name, because /chart returns no formatted labels at all. So the very first call a new integrator copied threw a TypeError. The README now carries a working example that derives the sign from the longitude (Math.floor(longitude / 30)), and every example in the changed sections was run against production before it was written down.

The error-handling section also gained 400 INVALID_FIELD: short coordinate names in a body are refused, and details names every offending field at once.

2026-08-10 · astroway 1.4.1 (Python), the quickstart example runs

What to do with your code. Nothing, unless you copied the quickstart out of the README. If you did, fix it: chart["angles"]["asc"] raises a KeyError.

The /chart response has no angles key. The ascendant is chart["houses"]["ascendant"], an ecliptic longitude in degrees rather than a sign name. The async example carried the same line and is fixed too. The error-handling section gained 400 INVALID_FIELD with its details array.

2026-08-10 · astroway/sdk 1.4.1 (PHP), the quickstart example runs

What to do with your code. Nothing, unless you copied the quickstart out of the README. If you did, fix it: $chart['angles']['asc'] is a key that does not exist.

The ascendant is $chart['houses']['ascendant'], an ecliptic longitude in degrees. The error-handling section gained 400 INVALID_FIELD; note that the code reads as $e->errorCode, since $e->code belongs to the base \Exception.

2026-08-10 · Short coordinate names are refused, and the error now names every field at once

What to do with your code. If you send lat, lon, lng, long, tz, timezone, timeZone or time_zone in a chart request body, rename them to latitude, longitude and timezoneOffset. If you already send the full names, nothing to do. Quick check: grep your code for "lat" and "tz" inside request bodies.

The refusal has been in effect since 2026-08-01, and it is not a deprecation. The short names were never part of the contract and never appeared in /openapi.json as body fields. They did not work, they were silently ignored: the coordinates carry a zero default, so the chart was computed for 0°N 0°E at UTC. The ascendant, the houses and everything derived from them came back wrong, with nothing in the response to say so. We are not taking the short forms back: that would mean two names for one field forever, and tz is ambiguous on top of it, since callers send both a number and a zone name under it.

What changed today is the shape of the refusal. It used to name one field at a time, so a body with three short names took three attempts. Now 400 INVALID_FIELD lists every field it found at once, in body order, adds details with { path, expected, message } for each (the same array INVALID_INPUT already carries), and a link to the documentation. path is the full path, so a synastry body shows which chart carries it: chart1.lat. The code is written up in Errors.

A nested point: { lat, lng } on /v1/acg-zones, /v1/acg/by-category, /v1/ccg-analysis and /v1/eclipse-analysis is unaffected: those are the declared field names there.

The ChartInput description in /openapi.json is fixed in the same pass. It named the short forms and described zero coordinates as an acceptable default. That description reaches 31 schemas, and with them the generated SDK types and the MCP tool descriptions. If your code or your agent was built against the old wording, re-read the new one.

latitude and longitude become required on 2026-11-09

The same trap from the other side. The coordinates carried a zero default, so a body without them also got a 200 describing 0°N 0°E: houses, angles and everything derived from them were computed there, with nothing in the response to say so.

What to do with your code. If you send latitude and longitude, nothing. If you don’t, add them before 2026-11-09.

Nothing breaks before 2026-11-09. A request without coordinates keeps working, but it stops being silent: the response carries Deprecation, Sunset and Warning headers plus a _warning field in the body saying the location was invented. From 2026-11-09 that body gets a 400 naming the missing field. We gave 90 days rather than the usual 12-month /v1 stability window because this is not a working capability being retired, it is a wrong answer no longer being served.

An explicit latitude: 0, longitude: 0 stays valid. The problem is the missing field, not the value: a caller who really means the Gulf of Guinea says so.

timezoneOffset keeps its zero default, because 0 there means UTC, a real value. And note that city is a label, not an input: no endpoint geocodes it, so it never stands in for coordinates.

A latitude outside ±90 or a longitude outside ±180 is now refused as well. Both used to pass.

2026-08-09 · POST /v1/ziwei/four-transformations, 四化 by year stem, with every school reading

A new endpoint returns the four stars activated by the birth year’s heavenly stem: 化禄 (fortune), 化权 (authority), 化科 (repute), 化忌 (obstruction). It is the one part of Zi Wei computable without placing stars into palaces, because it depends only on the year stem.

That stem comes from the exact Lichun instant, so a birth on the boundary day activates different stars depending on the hour. On 2025-02-03 at noon the stem is 甲 with 廉贞 in 化禄; at 23:59 it is 乙 with 天机.

The main point: where the traditions disagree, we return all of them. Seven of the ten stems read identically across every transmission we compared. Three (戊, 庚, 壬) do not, and for those the response carries schoolVariants with each school’s reading, flagged by disputed. The 庚 stem moves 化忌 as well as 化科, so ignoring the school question changes which star is afflicted, not merely which is credited.

We follow 中州派 by default. The school parameter switches to quanji, quanshu or beipai. If you are reconciling against a typical online calculator, use quanji: most of them ship that table. Tier 1.

2026-08-08 · /v1/status takes the key in a header, ?key= is deprecated

GET /v1/status now reads the key from the X-Api-Key header. The ?key= parameter still works but is deprecated, and responses to it carry Deprecation and Warning headers.

What to do with your code. Move the key out of the query string and into the header:

curl -H "X-Api-Key: aw_live_your_key" https://api.astroway.info/v1/status

The reason is not cosmetic. A URL is written to web server logs, to CDN logs and to browser history, so a key passed in a query string stops being a secret. Key values are redacted in our logs from now on, but what was written earlier is already written.

A removal date will be announced separately, with at least 90 days’ notice.

2026-08-07 · Stellaforge: birth-chart poster (/v1/reports/stellaforge)

A new endpoint renders a print-ready natal chart poster - a colored wheel (element sectors, degree labels, ASC arrow, MC marker, houses), the Sun/Moon/Rising trio, a placements table, element/modality balance, and the key aspects. Fully deterministic, 0 AI. Tier 7.

Three styles via style: editorial (light), celestial (dark + gold), classic (minimal). PDF by default, ?format=html returns HTML. White-label and multi-language supported. NB: style is read from the request body, not the query string. Details - Stellaforge.

2026-07-31 · /v1/match/score, dating compatibility in one call

New endpoint for dating apps: returns compatibility in a single request instead of separate synastry + attraction + your own flag logic. Tier 3. Same chart1 + chart2 input as /synastry.

Returns score (0-100) + label + harmony/tension + attraction (separate score) + topAspects (with tone) + greenFlags/redFlags. Numbers are identical to /synastry + /synastry/attraction-score - a re-shape of the same engine, not a new scoring model. Details - Dating & Compatibility API.

2026-07-28 · The Chinese calendar now comes from the ephemeris: exact solar terms, lunar months, local time for day and hour

Chinese solar-year and month boundaries are no longer read from a table of calendar dates. They are the actual instants: a solar term is the moment the Sun’s apparent longitude reaches a multiple of 15°, and a lunar month begins on the Beijing day containing a new moon.

This changes answers, not just wording. Lichun (立春) falls anywhere in February 3-5 and at any hour: 04:02 Beijing time in 2026, and on February 3 in 2025. The old “before February 4” rule put every birth on that day in one bucket. A birth on 2025-02-03 now returns Jia-Chen (Dragon) at noon and Yi-Si (Snake) at 23:59, as it should. The same applies twelve times a year at the month boundaries. If you cached /bazi/* or /chinese/* responses for dates near February 3-5 or near the start of any month, recompute them.

Every /bazi/* and /chinese/* endpoint now accepts optional time and timezoneOffset. They decide the answer near a boundary; without them the calendar assumes Beijing noon. Boundaries are always reckoned in China Standard Time, wherever the person was born.

Two bugs went with it. /v1/bazi/luck-pillars took the year stem from the Gregorian year instead of the solar year, so the sequence ran in the wrong direction for January births. /v1/chinese/zodiac/inner-animal mapped the Gregorian month number onto a branch directly, leaving every answer shifted by one position: mid-June returned Goat where the Wu month gives Horse.

Two new endpoints. POST /v1/chinese/solar-terms returns a year’s 24 terms as exact instants in UTC and Beijing time, flagging which ones open a pillar month. POST /v1/chinese/lunar-date converts a Gregorian date to the lunar calendar, including leap-month detection, and returns that year’s New Year date. Both Tier 1.

Day and hour pillars now follow local civil time. The hour branch was derived from the Beijing equivalent of the birth hour while the date stayed local, so /v1/bazi/hour-pillar and /v1/bazi/four-pillars returned different hour pillars for the same birth, and for timezoneOffset: 3 the day rolled forward at 18:00 instead of 23:00. Day and hour now follow the birthplace clock (the Zi branch opens the day at 23:00 local), while year and month stay bound to the Lichun and 節 instants. If you cached /bazi/* for births outside UTC+8, recompute them. /v1/bazi/hour-pillar gained a localHour field; cstHour stays.

POST /v1/bazi/luck-pillars now computes the real start age (起運) instead of a flat ten years. The distance from the birth to the bounding 節 converts to age at three days per year of life, so the first pillar’s ageStart is no longer 10. New fields: startAge (years and months) and startReference (which term was used as the bound).

Times in requests to /bazi/*, /chinese/* and /ziwei/* are now validated. Values such as 99:99:99 or 23:60:00 used to carry into the following day, and the answer described a date other than the one you sent. They now return 400. 24:00:00, meaning the midnight that ends the day, stays accepted. The same checks apply to /v1/compat/full, /v1/compat/astro-chinese, /v1/profile/spiritual-path and /v1/profile/multi-archetype, which fold in the Chinese layer.

POST /v1/chinese/solar-terms accepts years 2-2899 instead of 1900-2100, the same bound the rest of the Chinese endpoints use.

Most important: the day-pillar anchor was corrected. The reference point of the sixty-day cycle sat 29 positions off: the code held 1990-01-01 to be Yi-Wei where it is Bing-Yin. Every day pillar was therefore wrong, and with it the day master, the hour stem and all ten gods. Affected: /v1/bazi/four-pillars, /v1/bazi/day-master, /v1/bazi/hour-pillar, /v1/bazi/ten-gods, and the natal day master in /v1/bazi/yearly and /v1/bazi/monthly. Year, month and luck pillars are unaffected. If you stored any /bazi/* responses, recompute them in full. Easy to check against published dates: 1949-10-01 is 甲子, 2000-01-01 is 戊午, 2024-02-10 is 甲辰.

POST /v1/chinese/lunar-date returned a non-existent thirtieth day in a twenty-nine day month, swallowing the first day of the eleventh month. About 72 dates between 1900 and 2100, late November and early December: 2021-12-04 came back as “month 10, day 30” while the same endpoint reported the eleventh month as starting on 2021-12-04. Fixed and checked day by day across 73,414 dates.

Before 1929 the calendar is now reckoned in Beijing local mean time (UTC+7:45:40), which is the historical basis, rather than UTC+8. Three months before 1929 move, including Chinese New Year 1916 back to its historical February 3. A new moon falling within minutes of local midnight can still differ from the printed almanac of the period by a day, since those tables were computed to the accuracy of their own century. The endpoint says so in its response.

The four endpoints that fold in the Chinese layer (/v1/compat/full, /v1/compat/astro-chinese, /v1/profile/spiritual-path, /v1/profile/multi-archetype) now take the hour and timezone into account when resolving the animal, not just the date.

2026-07-27 · Zi Wei Dou Shu: the 14 main stars reference table corrected

POST /v1/ziwei/main-stars returned 14 entries of which only 13 were unique: 太阳 (Tai Yang) appeared twice, once as “Sun” and once as “Sun God”, while 巨门 (Ju Men, Giant Gate) was missing entirely. The response now carries all 14 canonical stars.

Names and romanisation are corrected. 天府 now reads pinyin Tian Fu (was Tian Hou, which is 天后, an unrelated deity); 武曲 is Martial Melody (was Big Dipper, which is 北斗七星, a constellation); 天梁 is Heavenly Beam (was Heavenly Mansion, a gloss belonging to 天府); 廉贞 is Chastity (was Distinguished Stars); 天同 is Heavenly Unity. Among the palaces, 疾厄宫 now reads pinyin Ji'e (was Jie'e), and the friends palace uses canonical 仆役宫 with pinyin Puyi (was colloquial 朋友宫 / Pengyou).

Array order is now canonical: the six stars of the 紫微 series first, then the eight of the 天府 series. A series field was added. If you matched stars by English name or by array index, that matching will break. The most stable key is chinese: it is unchanged for every star except the newly added 巨门.

The disclaimer field on /ziwei/* responses now states outright what previously lived only in a code comment: the palace and star tables are static, they do not vary with the birth date, and only solarYear and animal derive from it. Placing the stars into palaces is not implemented yet.

2026-07-24 · Muhurta API: activity catalogue + auspicious-dates report

Two new endpoints over the existing /v1/vedic/muhurat/*:

• GET /v1/muhurta/types: catalogue of the 12 activities (key + Sanskrit + description), free
• POST /v1/reports/muhurta: ready-made auspicious-dates report (PDF default, ?format=html), Tier 7

What to do: to pick a date for an event, choose an activity from /muhurta/types, scan a window via /vedic/muhurat/{activity} (JSON), or get the finished report directly via /reports/muhurta. Details - Muhurta API.

2026-07-17 · Cosmic Notifications: /webhooks/* events now fire automatically

Registered cosmic-event webhooks are now delivered automatically - previously a subscription could be created but nothing was ever sent. Live events (mundane, no natal data): retrograde-start, retrograde-end, sign-ingress, void-of-course-start, eclipse-alert (7 days before an eclipse).

What to do: if you registered /v1/webhooks/<event>, make sure your endpoint accepts a POST with the X-AstroWay-Signature: sha256=<hmac> header and verifies it (HMAC-SHA256(signing_secret, raw_body)). Event delivery is not metered; a subscription auto-disables after 5 consecutive failed deliveries. Details - Cosmic Notifications.

2026-07-11 · Vedic endpoints: sidereal lagna + local-time dashas

Every Vedic endpoint that relies on the lagna computed it from the tropical ascendant even though the planets were already sidereal: divisional charts (/vedic/varga/*), doshas (/vedic/doshas/*), Jaimini (/vedic/jaimini/*), compatibility (/vedic/compatibility/*), KP (/vedic/kp/*, including the house cusps), yogas (/vedic/yogas/*), Shadbala, Ashtakavarga, the rasi dashas (Chara/Sthira/Shoola) and Lal Kitab, plus the Vedic Kundli report. The lagna (and the cusps for KP/Shadbala) is now sidereal, and the varga response no longer returns ayanamsa: 0. For births where the tropical and sidereal ascendant fall in different signs, the lagna sign and everything derived from it (houses, doshas, arudhas, rasi dashas, KP sub-lords, house strengths) will change. This is a correction, not a regression.

Dasha period dates (Vimshottari and the other systems) are now in the birth’s local timezone instead of UTC (a 02:05 birth no longer shows as the previous day). The exact instant stays in the startJd/endJd fields. The fusion endpoints (/forecast/multi-system, /forecast/yearly-fusion) now also derive the mahadasha from the sidereal moon (they used the tropical one, which could return the wrong dasha lord) and show dates locally.

The timezone field accepts only a numeric timezoneOffset (hours from UTC). Sending a timezone name ("timezone": "Asia/Kathmandu") now returns 400 instead of silently computing in UTC.

What to do: recompute cached Vedic results, since the lagna sign may have shifted; read startJd/endJd for the exact dasha period instant; replace timezone names with a numeric timezoneOffset (e.g. 5.75).