2026-10-14 · Minor arcana names spelled out, court card elements, small tarot images
Changed value. name of the numbered minor arcana in every tarot deck is now spelled out: Nine of Swords instead of 9 of Swords, as in the localized names and on printed cards. slug is unchanged (9-of-swords).
Corrected value. astrology of the 16 court cards was written in reverse order: the Page of Swords is now earth of air, not air of earth. This is how the Golden Dawn writes the attribution.
New field. image.urlSmall and back.urlSmall: a 300 px wide picture (about 40 KB) for cards shown at up to about 150 px.
What to do with your code. If you compared the name of a numbered card with a string, compare slug instead. For small cards use urlSmall, or a srcset of the three sizes.
2026-10-14 · @astroway/render 0.2.2: axis lines no longer cross out planets
House cusp and axis lines (ASC, DSC, MC, IC) on the wheel-western wheel (and the bi-wheel, tri-wheel and composite) start past the planet ring instead of at its centre: a planet on a cusp or an axis is no longer crossed out by the line. The same renderer serves /v1/render/* and @astroway/render 0.2.2 on npm.
What to do with your code. Nothing. If you compare SVG byte for byte, refresh your references.
2026-10-14 · @astroway/render 0.2.1: planets no longer overlap
The wheel-western wheel (and the bi-wheel, tri-wheel and composite) spreads close planets along the ring instead of pushing them outward: glyphs and ℞ marks no longer touch each other or the house numbers in a dense chart, including a stellium and a group across 0° Aries. A moved glyph keeps a tick at its true degree with a thin line to it (aw-planet-pointer in the css theme). The same renderer serves /v1/render/* and @astroway/render 0.2.1 on npm.
What to do with your code. Nothing. If you compare SVG byte for byte or style wheel parts with CSS, refresh your references and add a style for aw-planet-pointer if you need one.
2026-10-14 · /v1/ziwei/chart: true solar time
POST /v1/ziwei/chart takes longitude and trueSolarTime, as /v1/bazi does. With trueSolarTime: true, longitude and timezoneOffset, the double-hour and the day are read from the sun over the birthplace, and the correction applied comes back in input.trueSolarTime. Without longitude or timezoneOffset such a request is a 400 TRUE_SOLAR_TIME_NEEDS_PLACE.
What to do with your code. Nothing: without trueSolarTime the answer is what it was, with input.trueSolarTime set to { "applied": false }. If your users were born far from their zone’s meridian (Spain, western France), send the longitude with trueSolarTime: true.
2026-10-14 · /v1/mayan/dreamspell counts the year
POST /v1/mayan/dreamspell ignored the year: a calendar date got the same kin in every year (1990-06-15 gave Kin 219). The kin is now a continuous count from 26 July 1987 = Kin 34 that skips 29 February, as in Argüelles’ system: 1990-06-15 is Kin 48, Solar Yellow Star. 29 February takes the kin of 28 February.
What to do with your code. No change needed, but kins you stored before were wrong for most dates: recompute them.
2026-10-13 · /v1/lunar-calendar in local days
POST /v1/lunar-calendar takes timezoneOffset (hours east of UTC) or timezone (an IANA zone such as Europe/Kyiv). With either, the calendar days become local days: dailyInfo[].date is local midnight, isVoC is read at local noon, phase and ingress fall on local days, and the month range of phases, ingresses, voidPeriods and moonAspects is local too. timezone follows a daylight-saving change inside the month, day by day. Before, timezoneOffset was accepted and ignored, so every offset got the same UT days.
What to do with your code. Without these fields nothing changed: days run in UT as before. If you sent timezoneOffset and shifted the days to your zone yourself, drop that shift: the API does it now.
2026-10-13 · Aspect isApplying fixed
The isApplying flag (whether an aspect is applying or separating) compared the orb now with the orb a whole day later. A fast Moon overshot an aspect that was hours from exact, and that aspect was marked separating; for some pairs the angle was measured along the longer arc and the sign came out wrong. The flag now comes from the sign of the orb’s rate of change at the moment. On our test charts 105 of 330 flags were wrong before, none are now. This applies to aspects and houseAspects in charts, transit aspects and horary. The daily isVoC in /v1/lunar-calendar now comes from voidPeriods in the same response: it is true when the day’s noon UT falls inside a void-of-course period. It used to be computed separately and disagreed with voidPeriods on about a third of days.
What to do with your code. Nothing, if you did not store isApplying. If you cached responses or texts built on “applying / separating”, recompute them: the value changed for about a third of aspects.
2026-10-13 · BaZi: a year forecast with gods, interactions, luck and twelve months
POST /v1/bazi/yearly now returns stemGod and branchGod (the god of the year stem and of the principal qi of its branch against the day master, with a code such as direct_officer) and interactions: the year against every pillar of the chart, namely 天干五合, 六合, 半合 and 拱合, a 三合 the year completes, 六沖, 刑, 六害, 六破, 伏吟 and 反吟. With gender it adds luckPillar, the luck pillar running at the target year’s Li Chun, and handoverInYear if the next pillar starts within that year. With includeMonths: true it adds months: twelve months from Li Chun to Li Chun, each opened by its 節, with start and end instants, gods and interactions.
POST /v1/bazi/monthly gains the same stemGod, branchGod and interactions, and its flavor now says “month” where it said “year”. Interactions in /bazi/chart and the symbolic stars carry a stable code, and strength in /bazi/chart gains favourableElementNames and unfavourableElementNames, as in /bazi/strength.
What to do with your code. Nothing: fields were only added. If you made twelve /monthly calls per year, one /yearly call with includeMonths: true returns the same months with boundaries at the exact 節 rather than at the 15th. branchInteractions in /yearly is unchanged; the fuller list is in interactions.
2026-10-13 · BaZi: the response names its conventions, the day boundary is a choice, ten gods and luck inside the chart
/v1/bazi/chart, the analysis routes, day-master, ten-gods, luck-pillars, yearly and monthly return conventions: the year and month boundaries, the day boundary, the solar-time correction, the zone with its offset and summer time, and the date of Chinese New Year. A new parameter dayBoundary: "23:00" | "midnight" (default "23:00", as before); a birth in the 23:00 hour gets alternateDay with the day pillar under the other rule. A date without a time on the day of Li Chun or a 節 gets boundaryInDay with both readings of the year and month pillars.
In /v1/bazi/chart every visible and hidden stem has a tenGod with a stable code, and includeLuck: true with gender adds luck, the same sequence /v1/bazi/luck-pillars returns. Every luck pillar now has ageStartExact with months, startDate, endDate, startYear, endYear and tenGod.
day-master, ten-gods, luck-pillars, yearly and monthly take trueSolarTime, longitude, timezone and dayBoundary exactly as /chart does, so one birth gives one day master on every route. In yearly and monthly, timezone resolves beside natalDate.
What to do with your code. Nothing: fields and parameters were only added, and no existing value changed. If you computed /yearly without the correction and /chart with it, pass the same trueSolarTime and longitude to both. The description of the hidden-stem weights in weighting is clarified: the weight follows the days each stem rules the month (人元司令), so on 辰戌丑未 the residual stem weighs 0.3 and the stored one 0.1. The numbers did not change.
2026-10-13 · Moon phase: meaning, degree, distance and the next phases
GET /v1/public/moon-phase returns more without a key: phaseKey (one of eight phases), moonDegree inside the sign, distanceKm to the Moon, next with the UTC moments of the next new moon, first quarter, full moon and last quarter, and meaning and keywords. The same meaning and keywords in the requested language are in localized.
What to do with your code. Nothing: fields are only added. The phase moments agree with the US Naval Observatory to the minute, so a widget no longer needs its own phase calendar.
2026-10-12 · Public compatibility returns localized names
GET /v1/public/compatibility/matrix and POST /v1/public/synastry now return a localized object that follows ?lang= or Accept-Language. The English identifiers (aries, trine, harmonious, identity) stay where they were and do not change.
What to do with your code. Nothing, if you match on the English values. If you kept your own translations of signs, relations, elements, spheres or compatibility labels, you can now take them from the response. In the matrix, localized is a set of lookup tables from identifier to name (signs, relations, tones, elements, modalities), not a translated copy of each of the 78 pairs. In synastry it is the translated label plus the tables labels, spheres, aspects and planets, keyed exactly as the aspects rows spell them.
The names come from the same explicit 21-language terminology table as the other localized blocks, not from machine translation.
2026-10-11 · Sign horoscope energy factors are structured
New fields. Every item of energy.factors in /v1/horoscope/{daily,weekly,monthly} and /v1/public/horoscope/* now carries kind: aspect (with planet1, aspect, planet2, ruler and the localised planet1Name, aspectName, planet2Name), moon (relation: sameElement, square or opposition, plus sign and signName) or house (planet, planetName, house).
What to do with your code. Nothing: the factor string and effect are unchanged. If you parsed factor with a regular expression to translate it, read the new fields instead.
2026-10-10 · C# / .NET SDK
New official package Astroway.Sdk on NuGet: every API endpoint as an async method (aw.Chart.ComputeAsync, aw.Render.WheelWesternAsync) with CancellationToken, retries on 408/409/429/5xx with Retry-After, one Idempotency-Key per POST, and one exception per kind of failure. DrawChartAsync draws a chart you already computed for 1 credit. .NET Standard 2.0 and .NET 8; the only dependency is System.Text.Json.
dotnet add package Astroway.SdkWhat to do with your code. Nothing, if you call the API from .NET with your own HttpClient. If you want a ready client, the quick start is on the SDK page.
2026-10-09 · Public bodygraph
POST /v1/public/human-design returns a bodygraph without a key: type,
strategy, authority, profile, defined centres, channels and gates. Same input
schema and same engine as the paid POST /human-design.
What to do with your code. Nothing, if you already use the paid route. If you kept Human Design in an iframe only because there was no anonymous JSON for it, you can render it yourself now.
The spec gained both public POST routes (/public/chart had never been
documented) and the query parameters of all fourteen /embed/* widgets, which
until now appeared to take no input at all.
2026-10-08 · Nine grahas in every varga, a public tarot deck catalogue, Personal Year defaults to this year
New field. POST /v1/vedic/varga/{D1..D60} returns grahas: the nine Jyotisha grahas (Sun, Moon, Mars, Mercury, Jupiter, Venus, Saturn, Rahu, Ketu) with longitude, sign and degree in the chosen varga. Ketu sits exactly opposite Rahu. planets is unchanged and still carries the outer planets and true Node.
New endpoint. GET /v1/public/tarot/decks, no key: the same answer as GET /v1/tarot/decks, cached for a day. The public spreads under /v1/public/tarot/* accept ?art=.
One field fewer required. year in POST /v1/numerology/{system}/personal-year is now optional and defaults to the current year in UTC.
What to do with your code. Nothing if planets is enough for you. For a Jyotisha interface, use grahas. Dosha details and yoga reason texts now name the sign (in Cancer) instead of a 1-based number; if you parsed them, move to the numeric fields.
2026-10-08 · Tarot returns localised card names
GET /v1/public/tarot/daily now reads ?lang= and Accept-Language and
returns a localized block. It used to ignore both signals, and the spec said
so.
"localized": { "cards": { "the-devil": { "name": "The Devil", "suit": "Major Arcana", "nameLocalized": true } }}localized.cards keys by the card slug, so you match on an identifier and never
on a translated string. The English name and slug are unchanged.
The 22 Major Arcana names and the four suit labels now come from an explicit terminology table in code, in 21 languages. Card keywords and meanings are prose and stay English.
Minor Arcana names are localised as well, composed from a rank and a suit form
frozen the same way the Major Arcana are. The joining is the part that does not
generalise, so each language carries its own format: English takes a
preposition, Ukrainian and Polish a genitive, German an article with it,
Hungarian and Turkish put the suit first and inflect the rank, Japanese joins
with no space, and Hindi agrees the possessive with the rank. The whole 78-card
deck reports nameLocalized: true; the field stays false only where the table
cannot name a card.
Separately, the POST /v1/public/human-design spec was corrected: it claimed
the response carried no localized block while the endpoint was already
returning one. localized is now in the response schema and in the example.
2026-10-07 · Destiny matrix: fold and centre fixed
Fix, values changed. POST /v1/destiny-matrix/ladini reduced numbers above 22 by subtracting 22, while the method sums the digits (39 is 12, not 17). The centre was wrong on almost every date as a result, and centre carried the bottom corner A+B+C. centre is now the real centre A+B+C+D; pointD, pointE, ancestral (the ancestral square corners) and personalPurpose are added. skyAxis is now B+D (the vertical), earthAxis A+C. karmicTailSum and moneyLineNode stay for compatibility; the first equals the centre, the second earthAxis.
What to do with your code. If you stored results, recompute them. Read the bottom corner from pointD and the centre from pointE or centre.
2026-10-07 · Go SDK
New official module github.com/astroway/astroway-go: every API endpoint as a method (aw.Chart.Compute, aw.Synastry.Compute, aw.Render.WheelWestern), context.Context on every call, retries on 408/409/429/5xx with Retry-After, one Idempotency-Key per POST, and errors you test with errors.Is. aw.DrawChart draws a chart you already computed for 1 credit. Standard library only, Go 1.22+.
go get github.com/astroway/astroway-goWhat to do with your code. Nothing, if you call the API from Go with your own HTTP client. If you want a ready client, the quick start is on the SDK page.
2026-10-06 · Tarot card pictures in an art set you pick, and a reading of the whole spread
New field. Every card in /v1/tarot/* and /v1/public/tarot/* responses carries image with url (600 px), url2x (1200 px), width, height and art; a draw also returns back, the card back. Pick the art with art (POST body or ?art= on a GET): rws-1909 (default), rws-restored and rws-vector for Rider-Waite-Smith, arnoult-1748 for Tarot de Marseille, dondorf for Lenormand (35 of 36 cards, the Moon has no picture). All sets are public domain. GET /v1/tarot/decks lists the decks, spreads and sets.
New endpoint. POST /v1/interpret/tarot writes a reading of a spread: each position in context, a synthesis and one piece of advice, in 21 languages. It takes card slugs or the drawn array of a draw response as it is. 100 credits, available on Free.
What to do with your code. Nothing if you do not need the pictures: the fields are only added. To show the cards, use card.image.url. Examples: Tarot.
2026-10-05 · TypeScript SDK 1.11.0: three request bodies fixed
Types regenerated from the current spec. Three methods carried another route’s body, so a typed call could not be written: aw.business.teamCompatibility({ founder, partner }), aw.horary.planetaryHours({ dayOfWeek, sunriseHour, sunsetHour }) and aw.mcp.multiChartContext({ charts, intent }). The new returnMoment, midpoint and Rider-Waite-Smith localized fields are typed.
What to do with your code. Nothing, if it worked. One type change: sign1 and sign2 on the sign compatibility body are now one of the twelve sign names rather than any string. The API never accepted anything else, but a variable typed as string needs narrowing.
The Python and PHP SDKs get the same spec in 1.10.1; their methods do not change.