Changelog що нового

Усі зміни, що впливають на код інтегратора: нові ендпоінти, оновлення SDK, зміни в /openapi.json, правки цін у кредитах, deprecation, breaking changes. Найновіші - згори. Внутрішні зміни сайту тут не фіксуються.

API-контракт стабільний у межах /v1/* - будь-яке breaking-зміна виходить під /v2/*, а /v1/* продовжує працювати щонайменше 12 місяців.

2026-10-15 · Тінь ретроградності, точні межі року за Личунем, ключ без ліміту

Нові поля. POST /v1/retrograde-periods повертає для кожного періоду shadowStart (планета вперше доходить до градуса, де стане директною) і shadowEnd (повертається до градуса, де стала ретроградною). POST /v1/chinese/zodiac/animal повертає yearStart і yearEnd: точні моменти Личуня, що обмежують сонячний рік, в UTC і за пекінським часом.

Змінене значення. GET /v1/auth/keys/me для ключа без ліміту кредитів віддає credits_remaining і credits_total_this_period як null разом з unlimited: true, а не 0.

Що робити з вашим кодом. Нічого, якщо ці поля вам не потрібні. Якщо ви показуєте баланс ключа, обробіть null.

2026-10-15 · Читання власного акаунта більше не коштує кредитів

Вісім ендпоінтів, які лише повідомляють стан вашого ключа, списували 10 кредитів за виклик. Тепер вони коштують нуль і не впираються у вичерпаний ліміт:

• GET /v1/auth/keys/me
• GET /v1/keys, GET /v1/keys/usage, GET /v1/keys/me/spend-cap
• GET /v1/webhooks, GET /v1/webhooks/{id}, DELETE /v1/webhooks/{id}
• GET /v1/mcp/tools-list

Друга частина була гіршою за саму ціну: перевірка кредитів відмовляла і при нульовій вартості, тож ключ, який щойно отримав 429, не міг прочитати власну статистику й дізнатися, чому. Тепер ці виклики проходять повз перевірку так само, як пісочничні ключі.

Дії лишаються платними, бо роблять щось незворотне: створення й ротація ключа, reveal, POST /v1/webhooks/subscribe, POST /v1/webhooks/{id}/test.

Якщо ваш код рахує X-Credits-Used після цих викликів, він тепер побачить 0.

2026-10-14 · Назви молодших арканів словами, стихії придворних карт, малі картинки таро

Змінене значення. name числових молодших арканів у всіх колодах таро тепер пишеться словами: Nine of Swords замість 9 of Swords, як у локалізованих назвах і на друкованих картах. slug не змінився (9-of-swords).

Виправлене значення. astrology 16 придворних карт записувалось у зворотному порядку: Паж Мечів тепер earth of air (земля в повітрі), а не air of earth. Так атрибуцію записує Золота Зоря.

Нове поле. image.urlSmall і back.urlSmall: картинка завширшки 300 px (близько 40 КБ) для карт до приблизно 150 px на сторінці.

Що робити з вашим кодом. Якщо ви порівнювали name числової карти з рядком, порівнюйте slug. Для дрібних карт беріть urlSmall або srcset з трьох розмірів.

2026-10-14 · @astroway/render 0.2.2: лінії осей не перекреслюють планети

Лінії куспидів і осей (ASC, DSC, MC, IC) на колесі wheel-western (і бі-, три-колесі, композиті) починаються за кільцем планет, а не з його середини: планета на куспиді чи осі більше не перекреслена лінією. Той самий рендер у /v1/render/* і в пакеті @astroway/render 0.2.2 на npm.

Що робити з вашим кодом. Нічого. Якщо ви порівнюєте SVG побайтово, оновіть еталони.

2026-10-14 · @astroway/render 0.2.1: планети не накладаються

Колесо wheel-western (і бі-, три-колесо, композит) розводить близькі планети вздовж кільця, а не виштовхує назовні: гліфи й позначки ℞ більше не торкаються одне одного й номерів домів у щільній карті, зокрема в стеліумі й у групі через 0° Овна. Зсунутий гліф лишає засічку на справжньому градусі з тонкою лінією до неї (aw-planet-pointer у темі css). Той самий рендер у /v1/render/* і в пакеті @astroway/render 0.2.1 на npm.

Що робити з вашим кодом. Нічого. Якщо ви порівнюєте SVG побайтово або фарбуєте елементи колеса через CSS, оновіть еталони й додайте стиль для aw-planet-pointer, якщо потрібно.

2026-10-14 · /v1/ziwei/chart: істинний сонячний час

POST /v1/ziwei/chart приймає longitude і trueSolarTime, як /v1/bazi. З trueSolarTime: true, longitude і timezoneOffset страж і день читаються за сонцем над місцем народження, а застосована поправка повертається в input.trueSolarTime. Без longitude чи timezoneOffset такий запит дає 400 TRUE_SOLAR_TIME_NEEDS_PLACE.

Що робити з вашим кодом. Нічого: без trueSolarTime відповідь та сама, що й раніше, input.trueSolarTime у ній дорівнює { "applied": false }. Якщо ваші користувачі народилися далеко від меридіана свого часового поясу (Іспанія, захід Франції), передавайте довготу з trueSolarTime: true.

2026-10-14 · /v1/mayan/dreamspell враховує рік

POST /v1/mayan/dreamspell раніше не враховував рік: одна й та сама календарна дата давала один кін у будь-якому році (для 1990-06-15 виходив Kin 219). Тепер кін рахується безперервно від 26 липня 1987 = Kin 34 з пропуском 29 лютого, як у системі Аргуельєса: для 1990-06-15 це Kin 48, Solar Yellow Star. 29 лютого отримує кін 28 лютого.

Що робити з вашим кодом. Нічого міняти не треба, але кіни, збережені раніше, для більшості дат були хибні: перерахуйте їх.

2026-10-13 · /v1/lunar-calendar за місцевою добою

POST /v1/lunar-calendar приймає timezoneOffset (години на схід від UTC) або timezone (зона IANA, наприклад Europe/Kyiv). З ними дні календаря стають місцевою добою: dailyInfo[].date дорівнює місцевій півночі, isVoC береться за місцевим полуднем, phase та ingress розносяться по місцевих днях, і межі місяця для phases, ingresses, voidPeriods і moonAspects теж місцеві. timezone враховує перехід на літній чи зимовий час усередині місяця, день за днем. Раніше timezoneOffset приймався, але не використовувався, тож будь-яке зміщення давало ті самі дні за UT.

Що робити з вашим кодом. Без цих полів відповідь не змінилася: дні, як і раніше, за UT. Якщо ви передавали timezoneOffset і перераховували дні на свою зону самі, приберіть це перерахування: тепер його робить API.

2026-10-13 · isApplying у аспектів виправлено

Прапорець isApplying (аспект сходиться чи розходиться) порівнював орб зараз з орбом через цілу добу. Швидкий Місяць перескакував аспект, до точності якого лишалися години, і такий аспект позначався як розбіжний, а для частини пар кут рахувався по довшій дузі, і знак виходив хибним. Тепер прапорець береться зі знаку зміни орбу в цю мить. На наших тестових картах раніше хибними були 105 прапорців із 330, тепер жодного. Це стосується aspects і houseAspects у картах, транзитних аспектів і хорару. Денний isVoC у /v1/lunar-calendar тепер береться з voidPeriods тієї самої відповіді: він true, коли полудень дня за UT потрапляє в період Місяця без курсу. Раніше прапорець рахувався окремо й розходився з voidPeriods приблизно в третині днів.

Що робити з вашим кодом. Нічого, якщо ви не зберігали isApplying. Якщо ви кешували відповіді чи тексти, побудовані на “сходиться / розходиться”, перерахуйте їх: значення змінилося приблизно для третини аспектів.

2026-10-13 · BaZi: прогноз на рік з богами, взаємодіями, удачею і дванадцятьма місяцями

POST /v1/bazi/yearly тепер повертає stemGod і branchGod (бог стовбура року і головного ці його гілки відносно денного господаря, з кодом на кшталт direct_officer) та interactions: рік проти кожного стовпа карти, а саме 天干五合, 六合, 半合 і 拱合, 三合, який рік завершує, 六沖, 刑, 六害, 六破, 伏吟 і 反吟. З gender додається luckPillar, стовп удачі на Lichun цільового року, і handoverInYear, якщо зміна стовпа припадає на цей рік. З includeMonths: true додається months: дванадцять місяців від Lichun до Lichun, кожен від свого 節, з моментами початку й кінця, богами і взаємодіями.

POST /v1/bazi/monthly отримав ті самі stemGod, branchGod і interactions, а в flavor замість “year” тепер “month”. Взаємодії в /bazi/chart і символічні зірки мають стабільний code, а strength у /bazi/chart отримав favourableElementNames і unfavourableElementNames, як у /bazi/strength.

Що робити з вашим кодом. Нічого: поля лише додано. Якщо ви робили дванадцять викликів /monthly на рік, один виклик /yearly з includeMonths: true дає ті самі місяці, межі яких проходять точно по 節, а не по 15-му числу. branchInteractions у /yearly лишився як був; повніший перелік лежить в interactions.

2026-10-13 · BaZi: відповідь називає свої конвенції, межа доби на вибір, десять богів і удача всередині карти

/v1/bazi/chart, маршрути аналізу, day-master, ten-gods, luck-pillars, yearly і monthly повертають conventions: межі року й місяця, межу доби, поправку на сонячний час, пояс зі зсувом і літнім часом, дату китайського Нового року. Новий параметр dayBoundary: "23:00" | "midnight" (типово "23:00", як і було); народження в годину 23:00 отримує alternateDay з денним стовпом за іншим правилом. Дата без часу на день Lichun або 節 отримує boundaryInDay з обома прочитаннями стовпів року й місяця.

У /v1/bazi/chart кожен видимий і схований стовбур має tenGod зі стабільним code, а includeLuck: true з gender додає luck, ту саму послідовність, що й /v1/bazi/luck-pillars. Кожен стовп удачі тепер має ageStartExact з місяцями, startDate, endDate, startYear, endYear і tenGod.

day-master, ten-gods, luck-pillars, yearly і monthly приймають trueSolarTime, longitude, timezone і dayBoundary так само, як /chart, тож одне народження дає одного денного господаря на всіх маршрутах. У yearly і monthly поле timezone розв’язується поруч із natalDate.

Що робити з вашим кодом. Нічого: поля й параметри лише додано, старі значення не змінилися. Якщо ви рахували /yearly без поправки, а /chart з нею, передайте ті самі trueSolarTime і longitude в обидва. Опис ваг схованих стовбурів у weighting уточнено: вага йде за днями правління (人元司令), тому на 辰戌丑未 залишковий стовбур важить 0.3, а збережений 0.1. Числа не змінилися.

2026-10-13 · Фаза Місяця: значення, градус, відстань і наступні фази

GET /v1/public/moon-phase віддає більше без ключа: phaseKey (одна з восьми фаз), moonDegree всередині знака, distanceKm до Місяця, next з моментами наступних молодика, першої чверті, повні й останньої чверті в UTC, а також meaning і keywords. Ті самі meaning і keywords мовою запиту лежать у localized.

Що робити з вашим кодом. Нічого: поля лише додано. Моменти фаз збігаються з US Naval Observatory з точністю до хвилини, тож окремий календар фаз для віджета більше не потрібен.

2026-10-12 · Публічна сумісність повертає локалізовані назви

GET /v1/public/compatibility/matrix і POST /v1/public/synastry тепер повертають об’єкт localized, який слідує за ?lang= або Accept-Language. Англійські ідентифікатори (aries, trine, harmonious, identity) лишилися на своїх місцях і не змінюються.

Що робити з вашим кодом. Нічого, якщо ви порівнюєте англійські значення. Якщо ви тримали власні переклади знаків, відношень, стихій, сфер чи міток сумісності, тепер їх можна брати з відповіді. У матриці localized це таблиці від ідентифікатора до назви (signs, relations, tones, elements, modalities), а не перекладена копія кожної з 78 пар. У синастрії це перекладена label і таблиці labels, spheres, aspects, planets, де ключі записані так само, як у рядках aspects.

Назви беруться з тієї ж явної таблиці термінів на 21 мові, що й решта блоків localized, без машинного перекладу.

2026-10-11 · Фактори енергії в гороскопах знаків зі структурою

Нові поля. Кожен елемент energy.factors у /v1/horoscope/{daily,weekly,monthly} і /v1/public/horoscope/* тепер має kind: aspect (з planet1, aspect, planet2, ruler і локалізованими planet1Name, aspectName, planet2Name), moon (relation: sameElement, square або opposition, плюс sign і signName) або house (planet, planetName, house).

Що робити з вашим кодом. Нічого: рядок factor і effect лишилися як були. Якщо ви розбирали factor регулярним виразом, щоб перекласти, беріть нові поля.

2026-10-10 · C# / .NET SDK

Новий офіційний пакет Astroway.Sdk на NuGet: кожен ендпоінт API як асинхронний метод (aw.Chart.ComputeAsync, aw.Render.WheelWesternAsync) з CancellationToken, повтори при 408/409/429/5xx з Retry-After, один Idempotency-Key на POST і окремий виняток на кожен тип помилки. DrawChartAsync малює вже пораховану карту за 1 кредит. .NET Standard 2.0 і .NET 8, єдина залежність System.Text.Json.

dotnet add package Astroway.Sdk

Що робити з вашим кодом. Нічого, якщо ви ходите в API з .NET власним HttpClient. Якщо хочете готовий клієнт, приклад на сторінці SDK.

2026-10-09 · Публічний бодиграф

POST /v1/public/human-design віддає бодиграф без ключа: тип, стратегія, авторитет, профіль, визначені центри, канали й ворота. Схема входу та рушій ті самі, що в платному POST /human-design.

Що робити з вашим кодом. Нічого, якщо ви вже користуєтесь платним маршрутом. Якщо ви тримали Human Design в iframe тільки тому, що анонімного JSON не було, тепер його можна рендерити на своєму боці.

У специфікації з’явилися обидва публічні POST-маршрути (/public/chart не був описаний ніколи) і параметри всіх чотирнадцяти /embed/*, які досі виглядали так, ніби не приймають вхідних даних.

2026-10-08 · Девʼять грах у варгах, публічний каталог колод таро, рік у Personal Year за замовчуванням

Нове поле. POST /v1/vedic/varga/{D1..D60} повертає grahas: девʼять грах джйотиші (Сонце, Місяць, Марс, Меркурій, Юпітер, Венера, Сатурн, Раху, Кету) з довготою, знаком і градусом у вибраній варзі. Кету стоїть точно навпроти Раху. Поле planets не змінилося: там і далі зовнішні планети й true Node.

Новий ендпоінт. GET /v1/public/tarot/decks без ключа: та сама відповідь, що й GET /v1/tarot/decks, кешується на добу. Публічні розклади /v1/public/tarot/* приймають ?art=.

Менше обовʼязкових полів. year у POST /v1/numerology/{system}/personal-year тепер необовʼязковий: без нього береться поточний рік за UTC.

Що робити з вашим кодом. Нічого, якщо вам вистачає planets. Для джйотиш-інтерфейсу беріть grahas. Тексти в details дош і reason йог тепер називають знак словом (in Cancer) замість номера з одиниці; якщо ви їх розбирали, переходьте на числові поля.

2026-10-08 · Таро повертає локалізовані назви карт

GET /v1/public/tarot/daily тепер читає ?lang= та Accept-Language і повертає блок localized. Раніше ендпоінт обидва сигнали ігнорував, і це було записано в спеці.

"localized": {
  "cards": {
    "the-devil": { "name": "Диявол", "suit": "Старший Аркан", "nameLocalized": true }
  }
}

Ключ у localized.cards - це slug карти, тому зіставлення йде за ідентифікатором, а не за перекладеним рядком. Англійські name і slug не змінилися.

Назви 22 Старших Арканів і чотирьох мастей тепер беруться з явної таблиці термінів у коді, у 21 мові. Ключові слова та значення карт лишаються прозою і приходять англійською.

Молодші Аркани теж локалізовані: назва збирається з рангу й форми масті, які заморожені так само, як і Старші. Складання це та частина, яка не узагальнюється, тому кожна мова має власний шаблон: англійська бере прийменник, українська й польська родовий відмінок, німецька ще й артикль, угорська та турецька ставлять масть першою і відмінюють ранг, японська з’єднує без пробілу, а гінді узгоджує присвійну частку з рангом. Уся колода з 78 карт має nameLocalized: true; поле лишається false тільки там, де таблиця не може дати назву.

Окремо виправлено спеку POST /v1/public/human-design: вона стверджувала, що блока localized немає, хоча ендпоінт його вже віддавав. Тепер localized описаний і в схемі відповіді, і в прикладі.

2026-10-07 · Матриця долі: виправлено згортання і центр

Виправлення, значення змінилися. POST /v1/destiny-matrix/ladini згортав числа понад 22 відніманням 22, а метод складає цифри (39 це 12, а не 17). Через це центр був неправильним майже на кожній даті, а поле centre несло нижній кут A+B+C. Тепер centre це справжній центр A+B+C+D; додано pointD, pointE, ancestral (кути родового квадрата), personalPurpose. skyAxis тепер B+D (вертикаль), earthAxis A+C. karmicTailSum і moneyLineNode лишилися для сумісності; перше дорівнює центру, друге earthAxis.

Що робити з вашим кодом. Якщо ви зберігали результати, перерахуйте їх. Нижній кут читайте з pointD, центр з pointE або centre.

2026-10-07 · Go SDK

Новий офіційний модуль github.com/astroway/astroway-go: кожен ендпоінт API як метод (aw.Chart.Compute, aw.Synastry.Compute, aw.Render.WheelWestern), context.Context у кожному виклику, повтори при 408/409/429/5xx з Retry-After, один Idempotency-Key на POST і помилки, які перевіряються через errors.Is. aw.DrawChart малює вже пораховану карту за 1 кредит. Лише стандартна бібліотека, Go 1.22+.

go get github.com/astroway/astroway-go

Що робити з вашим кодом. Нічого, якщо ви ходите в API з Go власним HTTP-клієнтом. Якщо хочете готовий клієнт, приклад запуску на сторінці SDK.

2026-10-06 · Картинки карт таро на вибір і тлумачення всього розкладу

Нове поле. Кожна карта у відповідях /v1/tarot/* і /v1/public/tarot/* має image з url (600 px), url2x (1200 px), width, height і art; розклад також повертає back, сорочку карти. Оформлення обирається параметром art (у тілі POST або ?art= у GET): для Rider-Waite-Smith rws-1909 (типово), rws-restored, rws-vector, для Марсельського Таро arnoult-1748, для Ленорман dondorf (35 з 36 карт, у Місяця картинки немає). Усі набори є суспільним надбанням. GET /v1/tarot/decks перелічує колоди, розклади й набори.

Новий ендпоінт. POST /v1/interpret/tarot пише тлумачення розкладу: кожна позиція в контексті, підсумок і порада, 21 мова. Приймає слаги карт або масив drawn з відповіді розкладу без змін. 100 кредитів, доступний на Free.

Що робити з вашим кодом. Нічого, якщо картинки вам не потрібні: нові поля лише додані. Щоб показати карти, беріть card.image.url. Приклади: Таро.

2026-10-05 · TypeScript SDK 1.11.0: три тіла запиту виправлено

Типи перегенеровано з поточної специфікації. Три методи раніше мали тіло чужого маршруту, тож типізований виклик не вдавалося написати: aw.business.teamCompatibility({ founder, partner }), aw.horary.planetaryHours({ dayOfWeek, sunriseHour, sunsetHour }) і aw.mcp.multiChartContext({ charts, intent }). Нові поля returnMoment, midpoint і localized у роздачах Таро Райдера-Вейта тепер типізовано.

Що робити з вашим кодом. Нічого, якщо він працював. Єдина зміна типів: sign1 і sign2 у тілі сумісності знаків тепер одна з дванадцяти назв знаків, а не довільний string. API інших значень і раніше не приймав, але змінну типу string доведеться звузити.

Python і PHP SDK отримують ту саму специфікацію у версії 1.10.1; їхні методи не змінюються.

2026-10-05 · Соляр шукається в запитаному році, лунар строго після дати, і обидва повертають момент

Виправлення. POST /v1/solar-return для дня народження з 1 грудня по 5 січня приблизно в половині років повертав соляр сусіднього року: народженим 15.12 на year: 2026 приходило 14.12.2025. Тепер повернення завжди належить запитаному року; для дня народження 1 січня момент може випасти на 31 грудня попереднього року за UTC. POST /v1/lunar-return міг повернути момент на кілька годин раніше за afterDate, якщо попереднє повернення було зовсім поруч; тепер результат завжди пізніший.

Якщо ви зберігали соляри для грудневих і ранньосічневих днів народження, перерахуйте їх.

Нові поля. Обидва ендпоінти повертають returnMoment, момент повернення в ISO 8601 UTC з точністю до секунди, щоб не перетворювати julianDay самостійно:

"returnMoment": "2027-05-10T07:43:11Z"

POST /v1/davison повертає midpoint з моментом і місцем, за якими побудована карта, а середня довгота тепер рахується по коротшій дузі: пара Токіо і Гонолулу дає 170.915, а не -9.085.

"midpoint": { "utc": "1991-06-30T22:30:00Z", "lat": 28.495, "lng": 170.915 }

2026-10-04 · Веб-компоненти @astroway/ui (альфа)

Новий пакет @astroway/ui: натальна карта, сітка аспектів, таблиця планет, фаза Місяця, планета дня, гороскоп, таро, сумісність знаків, синастрія і китайський знак як звичайні HTML-елементи. Один тег <script> з CDN або npm install @astroway/ui; працює в HTML, WordPress, Vue, Svelte, React 19 і Next.js.

Що робити з вашим кодом. Нічого, якщо ви малюєте самі. Якщо хочете готовий елемент: дані з вашого сервера через data, публічні елементи без ключа, або ключ pk_ для сайту в атрибуті api-key. Альфа: назви атрибутів ще можуть змінитися до 1.0. Докладно: Веб-компоненти.

2026-10-04 · Ключ для браузера створюється лише з бюджетом і областю

POST /v1/keys з origin_restriction.type: "public" (ключ класу pk_) тепер вимагає, крім списку доменів, ще два поля: credits_cap_cycle (скільки кредитів ключ може витратити за цикл, 0 паркує його) і allowed_endpoints (які шляхи він може викликати). Без будь-якого з них приходить 400. PATCH /v1/keys/{id} більше не дає зняти жодне з них у ключа pk_ (null відповідає 400), а ключ pk_, якому бракує бюджету чи області, відхиляється з 403 PUBLISHABLE_KEY_UNBOUNDED.

Що робити з вашим кодом. Якщо ви створюєте ключі pk_ скриптом, додайте до тіла credits_cap_cycle і allowed_endpoints. Серверних ключів це не стосується; credits_cap_cycle тепер також можна передати при створенні будь-якого ключа. Активних ключів pk_ без цих полів на момент зміни не було, тож нічого з уже виданого не зламалося.

2026-10-02 · Локалізовані назви у публічних відповідях

GET /v1/public/moon-phase і GET /v1/public/planet-of-day тепер повертають об’єкт localized, який слідує за ?lang= або Accept-Language. Англійські поля лишилися незмінними.

Що робити з вашим кодом. Нічого, якщо ви порівнюєте англійські значення: вони на місці й далі є стабільними ідентифікаторами. Якщо ви тримали власні карти перекладів для знаків, планет, днів тижня чи фаз Місяця, тепер їх можна прибрати й брати localized.

Назви беруться з явної таблиці термінів, а не з машинного перекладу. Це не косметика: у попередній схемі фазу Місяця перекладали послівно, і на всіх мовах роками віддавалося фінансове слово замість астрономічного терміна. Заразом це виправлено і у віджетах /v1/embed/*.

Відкриті множини поки що англійські й описані такими в документації: themes[] у планети дня, назви та значення карт Таро.

2026-10-01 · Human Design повертає локалізовані назви

POST /v1/public/human-design тепер повертає додатковий блок localized, що слідує за ?lang= та Accept-Language, як це вже роблять /public/moon-phase і /public/planet-of-day.

"localized": {
  "type": "Генератор",
  "strategy": "Чекай на сакральний відгук",
  "authority": "Емоційний (сонячне сплетіння)",
  "centers": { "SolarPlexus": "Сонячне сплетіння", "Spleen": "Селезінка" },
  "defined": "визначений",
  "open": "відкритий"
}

Англійські поля не змінилися: type, strategy, authority і назви центрів залишаються ідентифікаторами, за якими ви зіставляєте. Центри в localized ключуються тим самим ідентифікатором (SolarPlexus, а не перекладена назва), тож зіставлення не залежить від мови.

Доступно 21 мовою.

2026-09-30 · Статичні тлумачення натальної карти і ключ сайту для WordPress

GET /v1/natal-texts?keys=sun.aries,moon.h4,sun_moon.trine&lang=uk повертає відредаговані тексти тлумачень, до 64 ключів за виклик, за ціною одного звичайного виклику. Тексти не генеруються під запит. Зараз готові “планета в знаку” для 20 мов; “планета в домі” й аспекти додаються в міру готовності. Ключ, якого ще немає мовою запиту, приходить у missing, без підстановки іншої мови.

POST /v1/site-keys видає ключ сайту WordPress, який довів, що контролює свій домен. Такий ключ працює лише з цим доменом, на наборі безкоштовних читань, 300 викликів на годину.

Власник сайту може перевести його на ключ свого акаунта в один клік: сторінка /dashboard/connect повертає в адмінку одноразовий код, а сервер сайту обмінює його через POST /v1/site-keys/connect/exchange на ключ акаунта. Ключ сайту перестає діяти через 24 години після обміну.

Що робити з вашим кодом. Нічого, якщо ці можливості вам не потрібні. Якщо ви показуєте натальну карту, тексти тепер можна брати без AI і без окремої ціни за кожен.

2026-09-28 · DPA приймається кнопкою, і три нові ендпоінти навколо цього

GET /v1/me/dpa каже, яка версія угоди чинна і чи прийняв її ваш акаунт. POST /v1/me/dpa/accept приймає її. GET /v1/me/dpa.pdf віддає PDF, у якому надрукований запис про прийняття: акаунт, версія, дата й час. Усі три під Bearer-токеном акаунта, кредитів не коштують.

Що робити з вашим кодом. Нічого, якщо DPA вам не потрібна. Якщо ваш юрист її вимагає: прочитати текст на /legal/dpa/, прийняти в дашборді або цим ендпоінтом і забрати PDF. Раніше сторінка обіцяла підписану копію протягом п’яти робочих днів, і підписувати її не було кому; стаття 28 п. 9 GDPR приймає договір “у письмовій формі, в тому числі електронній”, тож запис про прийняття і є та форма.

Одне уточнення, яке варто прочитати саме юристу. Дані лежать і рахуються в Нюрнберзі, але адмініструємо ці машини ми з України. Глава V GDPR вважає передачею у третю країну і віддалений доступ, навіть коли нічого не копіюється, тому §6 угоди це прямо називає і відсилає до Стандартних договірних положень, замість формулювання “жодної транскордонної передачі”, яке стояло на сторінці раніше й не було правдою.

2026-09-27 · Панчанг: йога рахується від сидеричних довгот

POST /v1/vedic/panchang/yoga, POST /v1/vedic/panchang/full і всі POST /v1/vedic/muhurat/* рахували йогу від тропічних довгот Сонця і Місяця. Йога це сума двох довгот, тому аянамша входить у неї двічі, і результат був зсунутий приблизно на чотири йоги з 27. Тепер довготи сидеричні, з аянамшею із запиту (за замовчуванням Лахірі). Для Києва 21.09.2026 відповідь збігається з drikpanchang: Shobhana до 13:36, далі Atiganda.

Що робити з вашим кодом. Якщо ви зберігали yoga або вікна мухурти, перерахуйте їх: змінились yoga.number, yoga.name, sumLongitude, а у мухуртах також набір і порядок вікон, бо йога входить в оцінку. Титхі, карана, накшатра і вара не змінились.

Там само виправлено дві схеми. /v1/embed/kundli ставив сидеричні грахи в тропічну лагну, і кожен дім був зсунутий на знак. /v1/render/wheel-vedic-north, -south і -east з zodiacType: "sidereal" тепер переносять у сидеричний зодіак і доми, а не лише планети.

2026-09-26 · MCP по доменах: один предмет замість 782 інструментів

https://mcp.astroway.info/mcp/<домен> віддає один предмет із чотирнадцяти: core, vedic, chinese, hellenistic, tarot, numerology, human-design, forecast, relationships, psychological, divination, applied, reports, platform.

Що робити з вашим кодом. Нічого, якщо вас влаштовує повний каталог: /mcp не змінився й віддає всі 782 інструменти. Якщо агент працює з однією темою, поміняйте URL у конфігурації клієнта на домен: відповідь tools/list падає з 2.9 МБ до 107-970 КБ, і агент читає менше, перш ніж вибрати інструмент.

Перевірка балансу й оцінка вартості є в кожному домені, бо агент, обмежений однією темою, все одно має знати, скільки коштує виклик.

GET /domains повертає список як JSON, без ключа. Невідомий домен це 404 з переліком справжніх, а не мовчазне повернення всього каталогу.

2026-09-25 · Невідомий час народження: карта без вигаданих домів і кутів

POST /v1/chart і POST /v1/synastry приймають timeUnknown: true замість time. У цьому режимі повертаються планети та аспекти, а houses, houseAspects, chartSect і siderealTime приходять як null.

Що робити з вашим кодом. Нічого, якщо ви завжди знаєте час народження: без прапорця time лишається обов’язковим, а відповідь не змінилася. Якщо ви досі підставляли умовний полудень для користувачів без часу, замініть це на timeUnknown: true і перестаньте показувати асцендент, якого насправді ніхто не рахував.

Разом із картою приходить блок timeUnknown: припущений момент (локальний полудень), перелік пропущених полів і положення Місяця на початок та кінець доби. Місяць проходить за добу від 11.8 до 15.4 градуса і може змінити знак, тому в блоці є і дуга, і список знаків, і прапорець changesSign. Аспекти з Місяцем у цьому режимі ненадійні, про що каже moonAspectsUncertain.

Решта ендпоінтів прапорець не приймає і відповідає 400 TIME_UNKNOWN_UNSUPPORTED. Транзити, прогресії, дирекції, профекції, домові накладення в синастрії будуються від кутів або домів, тож без часу народження там немає що повертати.

2026-09-24 · Компактна відповідь: fields і precision на кожному ендпоінті

Два параметри запиту скорочують відповідь на останньому кроці. fields це список шляхів через кому відносно data, застосовується до кожного елемента масиву: planets.name означає назву кожної планети. precision це ціле від 0 до 15, округлює всі нецілі числа й не чіпає цілі.

Що робити з вашим кодом. Нічого, якщо ви читаєте всю відповідь: без цих параметрів нічого не змінилося. Якщо ви віддаєте відповідь моделі, спробуйте їх: POST /v1/chart з ?fields=planets.name,planets.longitude&precision=2 це 778 байтів замість 32 410.

Шлях, який нічого не знайшов, приходить у _fields_unmatched, а не зникає. Необов’язкові поля справді відсутні в частині відповідей, тож це не помилка. Але список, де не збіглося жодного шляху, повертає 400 FIELDS_UNKNOWN з переліком: порожній об’єкт замість карти був би впевненою неправильною відповіддю.

Обидва параметри є в /openapi.json на всіх 770 операціях, тож генератори SDK підхоплять їх самі. Вони навмисно в query, а не в заголовку: кеш відповідей ключується за query, і режим у заголовку віддавав би компактну відповідь тому, хто просив повну.

2026-09-24 · Межі для крокових полів на трьох ендпоінтах

Три поля, що ділять діапазон на кроки, тепер мають межі й відповідають 400 замість того, щоб приймати значення, з яким запит не завершується:

• POST /v1/rectification: stepMinutes від 0.5 до 240, searchRangeMinutes до 1440, orb до 15. Додатково перевіряється частка: більш ніж 1440 кандидатів на один запит не приймається.
• POST /v1/aspect-timeline і POST /v1/aspect-bar: stepDays від години до року, maxOrb до 30, і не більш ніж 5000 точок ефемерид на запит.

Там же weight у подіях ректифікації тепер має бути більшим за нуль і не більшим за 3, а type приймає лише значення з переліку. Раніше подія без ваги давала score: null в усіх кандидатів.

Списки в тілі запиту теж мають межі, бо це лічильники циклів:

• planet1Ids, planet2Ids, visiblePlanetIds, planetIds, transitPlanetIds - не більш ніж 32 елементи, кожен цілий і невід’ємний. /v1/aspect-timeline перемножує два таких списки на список аспектів і на діапазон, тож без межі це множення без стелі.
• aspectAngles - не більш ніж 64 кути, кожен у межах 0..360. Кут поза цим діапазоном не міг збігтися ні з чим і давав порожній результат замість 400.
• events у ректифікації - не більш ніж 20, parts в арабських частках - не більш ніж 64.

POST /v1/retrograde більше не повторює той самий скан: дубльований id планети раніше запускав багаторічний прохід ще раз і повертав кожен ретроград двічі.

Координати спостерігача тепер обмежені там, де ендпоінт оголошує власну пару: point у /v1/eclipse-analysis і /v1/ccg-analysis, latitude та longitude у /v1/vedic/kp/horary. Широта 500 давала 200 з видимістю затемнення і смугою повної фази для точки, якої немає. Там же year у /v1/moon-aspects обмежений роками, які взагалі може виразити дата.

Якщо ваш код надсилає щось із цього поза межами, він отримає 400 з полем у error.details замість відповіді, на яку не можна покластися.

2026-09-23 · /v1/horoscope/compatibility приймає лише знаки зодіаку

sign1 і sign2 тепер одне з дванадцяти значень, від aries до pisces, у /openapi.json це enum. Регістр і пробіли по краях не важливі: Aries і LEO приймаються.

Що робити з вашим кодом. Нічого, якщо ви передаєте назви знаків англійською. Будь-що інше раніше доходило до моделі як є і давало текст про вигадану пару, тепер це 400 з назвою поля.

2026-09-22 · /v1/reports/generate коштує стільки, скільки звіт, який він будує

Диспетчер звітів списував 10 кредитів незалежно від report_type. Тепер він списує ціну цільового звіту: natal це 5000, tarot це 100, і так для всіх дванадцяти типів. Рівно те саме, що й прямий виклик /v1/reports/natal.

Що робити з вашим кодом. Перерахуйте бюджет, якщо ви ходите через диспетчер: та сама кількість викликів тепер коштує стільки ж, скільки прямі шляхи, а не в п’ятсот разів менше. Відповідь, схема й заголовки не змінилися, змінилося тільки число в X-Credits-Used.

На Free-плані диспетчер більше не проходить. Обмеження плану читалося з ціни ендпоінта, а ціна була заниженою, тому PDF-звіти відкривалися там, де план їх не включає. Тепер обмеження береться від цільового звіту, і виклик повертає 402 PLAN_UPGRADE_REQUIRED, як і прямий шлях. Те саме для пісочниці та для пакетів.

Це виправлення обіцянки, а не зміна політики: анонс диспетчера від 2026-05-15 казав, що виклик через report_type коштує рівно стільки ж, скільки прямий. Чотири місяці це було неправдою, і сторінка /credits/ більше не друкує одне число біля ендпоінта, ціна якого залежить від тіла запиту.

2026-09-21 · Документація як MCP-сервер, без ключа

https://mcp.astroway.info/mcp/docs відповідає без авторизації, бо жоден із його інструментів не витрачає кредитів.

• find_endpoint шукає серед усіх 770 операцій і для кожної віддає метод, URL, ціну в кредитах, тариф, обов’язкові поля тіла й посилання на довідку. Ціну мають 700 операцій, ще 37 позначені як безключові.
• search_docs шукає по 281 сторінці посібників, українських і англійських.
• read_doc віддає одну сторінку як markdown.
• list_docs показує весь покажчик за розділами.

Що робити з кодом. Нічого. Це нова адреса поруч із наявними, старі конфіги не змінюються. Якщо ви підбираєте ендпоінти для агента, тепер вартість сценарію можна порахувати до того, як з’явився ключ.

2026-09-21 · MCP-інструменти приймають fields і precision, і більше не шлють дані двічі

Кожен інструмент на mcp.astroway.info тепер приймає два параметри поверх своїх: fields, список шляхів через кому відносно data, і precision, скільки знаків після коми лишити. Це ті самі параметри, що й у REST, і вони потрапляють до API тим самим query.

Що робити з кодом. Нічого, якщо вас влаштовує повна відповідь. Якщо ваш агент читає з карти дві колонки, назвіть їх: натальна карта через MCP важила 91 737 байтів, а з трьома шляхами й precision: 2 це 1 182. Кредити однакові, платить той, хто читає.

Текстовий блок у відповіді інструмента більше не форматується з відступами. Він і далі повторює те саме, що й структуроване поле, бо цього вимагає сумісність зі старими клієнтами, але самі лише відступи на одній карті важили 13 313 байтів.

Виправлено: шістдесят інструментів-довідників відповідали 404. Вони звертались до GET-ендпоінтів методом POST, тож усі двадцять чотири колоди Таро, таблиці зодіаку й езотерики, /acg/categories, /muhurta/types, /kabbalah/shem-names відповідали 404 NOT_FOUND відтоді, як з’явились. Ті самі інструменти в stdio-пакеті @astroway/mcp працювали. Ще двадцять інструментів із параметром у шляху не підставляли його в URL. Обидва випадки виправлені, нічого міняти у своєму коді не треба.

2026-09-21 · timezone: надішліть назву зони, і зсув для тієї дати обчислиться сам

Кожен запит, що приймає timezoneOffset, тепер приймає й timezone: назву IANA, наприклад Europe/Kyiv, або auto, щоб визначити зону за latitude і longitude. Сервер бере зсув, який тримали годинники цієї зони в ту місцеву дату й час, разом із літнім часом, і використовує його замість timezoneOffset.

Що робити з кодом. Нічого, якщо ви вже надсилаєте правильний зсув. Якщо ви рахували зсуви самі, можна надсилати зону. Коли приходять обидва поля, діє timezone, тож модель SDK, яка завжди надсилає timezoneOffset: 0, не заважає.

Чому це важливо: у зсуві легко помилитися на годину. Київ 1990-05-15 жив за московським літнім часом, UTC+4, а не +3, а пропущений зсув і далі означає UTC.

Час, що був двічі (коли годинники переводили назад), береться за першим разом; час, якого не було (коли переводили вперед), отримує зсув, що діяв до переведення. Абревіатури на кшталт EST відхиляються з 400 INVALID_FIELD, бо EST це фіксовані -5 цілий рік. До 1970 року база часових поясів надійна не для кожного місця, тож для давніших народжень із відомим місцевим часом надсилайте timezoneOffset.

timeZone, time_zone і tz із назвою тепер відсилають у повідомленні INVALID_FIELD до timezone, а не до timezoneOffset.

2026-09-18 · Специфікація більше не просить ключ там, де він не потрібен

Тридцять сім операцій відповідають без ключа: дев’ять під /v1/public/*, чотирнадцять під /v1/embed/* і чотирнадцять довідникових під /v1/reference/*. У openapi.json двадцять вісім із них успадковували загальну схему ApiKeyAuth, тобто документ стверджував, що ключ потрібен, хоча кожен із цих маршрутів змонтований до перевірки авторизації і завжди відповідав анонімно.

Що робити з вашим кодом. Нічого, якщо ви вже ходите на них без ключа: поведінка не змінилась і не змінюється. Якщо ви генеруєте клієнт зі специфікації, перегенеруйте його: ці операції перестануть вимагати credential, а security: [] тепер стоїть явно.

Заразом виправлено те, що ці ж сторінки документації радили надсилати ключ, а їхні markdown-двійники не показували приклад виклику.

2026-09-18 · Bhava Bala: сила дванадцяти домів у ведичній карті

POST /v1/vedic/bhavabala. Shadbala у нас рахувала силу планет, але не домів. Bhava Bala це її прямий супутник за тим самим розділом BPHS.

Що робити з вашим кодом. Нічого, якщо ви не рахуєте силу домів. Якщо рахували самостійно поверх /vedic/shadbala/full, тепер це один виклик, і сила володаря дому береться з того ж коду, що й /shadbala/full, тож розбіжності між двома відповідями бути не може.

На кожен дім повертаються три складові окремо: Bhavadhipati Bala (Shadbala володаря), Bhava Digbala (клас знаку на середині дому і його напрямок) і Bhava Drishti Bala (чисте сальдо аспектів). Плюс сума у вірупах і рупах, ранг, найсильніший і найслабший дім.

Ендпоінт позначений yellow: він успадковує статус Shadbala, де модель аспектів спрощена до цілознакової. Digbala і класи знаків при цьому точні за побудовою.

2026-09-17 · Публічні ендпоінти показують обидва лічильники ліміту, а не лише найтісніший

Запит до /v1/public/* із заголовком X-AstroWay-Site-URL рахується за двома лічильниками одночасно: 300 на годину для заявленого сайту і стеля 600 на годину для адреси. Стандартні заголовки X-RateLimit-* описують лише найтісніший з них, тому другий був невидимий. Тепер відповідь несе обидва:

X-RateLimit-Scope: site
X-RateLimit-Limit: 300
X-RateLimit-Remaining: 297
X-RateLimit-Counters: ip=597/600, site=297/300

Формат - scope=залишок/ліміт через кому. Заголовок приходить тільки тоді, коли лічильників справді два: анонімний виклик із X-AstroWay-Site-URL. Виклик із платним ключем рахується за ключем і за тарифом, там лічильник один і заголовка немає. Він є і на відповіді 429, де потрібен найбільше.

Ліміти не змінилися. Змінилося те, що про них видно.

Що зробити з вашим кодом. Якщо ви рендерите з сервера кілька доменів з однієї адреси, читайте X-RateLimit-Counters, а не тільки X-RateLimit-Remaining: корзина сайту в кожного домену своя, а стеля на IP спільна на всі, і впирається саме вона.

2026-09-14 · Прострочений план ще три дні відповідає, а не повертає 402

Коли оплачений період закінчується, запити тепер ще 3 дні обслуговуються за вашим тарифом. Раніше 402 SUBSCRIPTION_EXPIRED приходив у ту ж секунду, коли спливав expires_at, і інтеграція зупинялась, щойно оплата запізнилась.

Що робити з вашим кодом. Нічого обов’язкового. Якщо хочете дізнатися про прострочення раніше за своїх користувачів, логуйте X-Subscription-Status: grace і X-Subscription-Grace-Ends: вони приходять тільки в ці три дні. Після них відповідь, як і раніше, 402 SUBSCRIPTION_EXPIRED, а в details тепер є expired_at і grace_ended_at.

Те саме стосується add-on паків.

2026-09-13 · houseSystem відхиляє код, якого не існує

Раніше поле приймало будь-який рядок. Рушій читає з нього тільки першу літеру, тож невідома літера мовчки давала Placidus, а у відповіді houses.system повторював те, що ви надіслали. Тобто карта, порахована за Placidus, поверталася підписана системою, якої в розрахунку не було.

Тепер приймаються рівно ті 25 кодів, які вміє рушій: P K R C E W B M O A T V D F G H I i L N Q S U X Y. Регістр значущий, I та i це різні системи. Усе інше отримує 400 з переліком у тексті помилки.

Що робити з вашим кодом. Нічого, якщо ви надсилаєте код літерою або не надсилаєте поле зовсім: типове значення лишилось P. Якщо ви надсилали назву ("Placidus", "Koch"), запит почне повертати 400: раніше він працював випадково, бо збігалася перша літера, і так само випадково "Zodiac" давав Placidus. Замініть назву на код.

Перевірено на проді до зміни: houseSystem: "ZZZ" повертав куспід 2 на 192.865, байт у байт як "P", і при цьому system: "ZZZ".

2026-09-13 · allowlist більше не значиться в специфікації

origin_restriction.type: "allowlist" прибрано з openapi.json: у схемах CreateKey і UpdateKey лишилось два значення, server-only і public.

Що робити з вашим кодом. Нічого. Значення приймається й далі та означає те саме, що public, тож наявні виклики працюють без змін. Якщо ви генеруєте клієнт зі специфікації, після оновлення в ньому просто не буде третього варіанта, який дублював другий.

Це той анонсований крок, про який ішлося 12 вересня, коли обидва написання почали створювати однаковий ключ класу pk_. Прибрано саме з документа, а не з приймання: відмовляти у значенні, яке специфікація перелічувала ще вчора, гірше, ніж чесно сказати, що воно застаріле.

2026-09-13 · Ключ можна обмежити списком ендпоінтів

POST /v1/keys і PATCH /v1/keys/{id} приймають allowed_endpoints: список шляхів під /v1, точних (chart) або просторів імен (embed/*). Ключ зі списком викликає тільки те, що в списку, незалежно від тарифу.

Що робити з вашим кодом. Нічого, поки не задасте список: без нього поведінка не змінилась, і зараз списку немає в жодного ключа. Якщо задаєте, обробіть 403 ENDPOINT_NOT_IN_SCOPE, у details приходить сам список. null знімає обмеження, порожній список не приймається, бо читався б і як “усе”, і як “нічого”.

Обмеження діє на обидва класи ключів і на /v1/public/* та /v1/embed/* теж. Службові читання (/v1/auth/keys/me, /v1/keys/usage) з-під нього не звільнені, на відміну від кредитів: область це право, яке ви виписали ключу, а не тарифікація, і ключ у вихідному коді сторінки не повинен віддавати витрати акаунта.

2026-09-13 · Ключ для браузера став окремим класом pk_

POST /v1/keys з origin_restriction.type: "public" тепер видає ключ із префіксом pk_live_ або pk_test_ і вимагає непорожній allowed_origins: без списку приходить 400. Для цього класу правило походження зворотне до звичайного. Запит без Origin і без Referer отримує 403 ORIGIN_REQUIRED, а не проходить як серверний, і Origin: null з <iframe sandbox> рахується відсутнім походженням, а не дозволом.

Що робити з вашим кодом. Нічого, якщо ви користуєтесь звичайними ключами: aw_live_ і aw_test_ поводяться як раніше, режими server-only та allowlist не змінились, і жоден наявний ключ не переведено. Якщо ви розбираєте префікс ключа на своєму боці, додайте pk_. Якщо створюєте ключі через API з type: "public", додайте до запиту список доменів.

Раніше цей режим означав “будь-який origin”, тобто ключ, призначений лежати у вихідному коді сторінки, працював і з curl без жодного заголовка. Ключі, створені до 13 вересня, працюють як працювали; змінюється тільки те, що видається далі.

Заразом ключ, надісланий на /v1/public/* або /v1/embed/*, тепер справді перевіряється. Ці два префікси змонтовані до перевірки авторизації, тому політика походження на них не виконувалась зовсім: той самий server-only ключ отримував 403 на /v1/keys/usage і 200 на /v1/embed/moon-phase з тим самим чужим Origin. Запит без ключа на цих префіксах не змінився: він і далі анонімний, з лімітом за IP, бо саме так до нас приходить кожен віджет в <iframe>.

type: "allowlist" тепер видає той самий клас pk_, що й type: "public". Раніше цей режим створював секретний ключ, який приймався з перелічених доменів, але так само проходив і без походження взагалі, бо це звичайний серверний пропуск. Тобто саме той режим, який документація радила для віджетів, лишався слабшим. Значення нікуди не зникло і далі приймається, щоб не ламати згенерованих клієнтів: воно просто створює те саме, що public, і відповідь це показує - префікс ключа pk_ і origin_restriction.type: "public". Наявні ключі зі списком не переведені й працюють як працювали.

2026-09-13 · Ліміт запитів ділиться між дозволеними походженнями

Якщо у ключа є список дозволених походжень, кожен запис списку тепер отримує власну частку ліміту запитів: ліміт ключа поділений на кількість записів, округлено вгору. Раніше будь-яке одне походження могло вибрати весь ліміт ключа.

Що робити з вашим кодом. Нічого, якщо в списку один запис: частка дорівнює лімітові й поведінка не змінилась. Якщо записів кілька, врахуйте, що один ваш сайт більше не займе квоту решти. Додався 429 з поясненням, який саме запис вичерпано, і два заголовки, X-RateLimit-Origin-Limit та X-RateLimit-Origin-Remaining; вони приходять лише на запитах, пропущених за записом зі списку.

Лічильник ведеться за записом списку, а не за хостом, який прийшов: *.example.com це один лічильник на всі піддомени. Інакше обмеження обходилось би вигадуванням нового піддомена на кожен запит.

2026-09-13 · Модель сумісності перерахована, числа змінились

Бал сумісності рахується за новою моделлю. Поля ті самі (score, label, harmony, tension), типи ті самі, числа інші в кожній парі. Додалось поле top: п’ять найвагоміших аспектів, кожен зі своїм strength і знаком sign.

Зачеплені /v1/synastry, /v1/match/score, /v1/group-synastry, /v1/public/synastry і віджети на /v1/embed/*.

Що робити з вашим кодом. Якщо ви зберігали бал у себе, перерахуйте: та сама пара тепер дає інше число. Якщо ви порівнюєте бали між парами або сортуєте за ними, нічого робити не треба, шкала лишилась 0-100. Порогів ми не змінювали: challenging до 40, mixed до 52, balanced до 64, вище harmonious.

Чому. Попередня формула була harmony / (harmony + tension), і на краях вона ламалась: один трин давав рівно 100, один квадрат рівно 0, а з’єднання Сонця з Сатурном рахувалось гармонією. Нова модель зважує аспект і пару тіл, враховує мінорні аспекти, читає з’єднання по тілу, а не по парі, і нормує результат так, щоб середина шкали була серединою.

Разом з цим /v1/match/score перестав суперечити сам собі: його greenFlags і redFlags рахувались за старим правилом з’єднання, тож один і той самий аспект міг бути “зеленим прапорцем” і водночас входити в tension. Тепер прапорці й бал говорять одне й те саме.

Там же змінився порядок topAspects. Він рахувався окремою формулою ваги, тож “головні” аспекти не збігались з тими, з яких склався бал. Тепер це та сама вага, що й у top, і той самий порядок. Якщо ви берете topAspects[0] як головний аспект пари, це тепер інший аспект.

2026-09-12 · Бюджет кредитів на окремий ключ

Кредити спільні на весь акаунт, тож один ключ міг витратити їх усі. PATCH /v1/keys/{id} тепер приймає credits_cap_cycle: стеля саме для цього ключа, у кредитах за цикл.

Що робити з вашим кодом. Нічого, якщо бюджет не задавати: без нього поведінка не змінилась. Якщо задаєте, обробіть новий 429 KEY_BUDGET_EXHAUSTED. Він приходить, коли ключ вичерпав свій бюджет, навіть якщо на акаунті кредити ще лишились, і навіть на тарифі з overage: бюджет, який можна перевитратити за гроші, це не бюджет.

null знімає обмеження, 0 означає ключ, яким не можна витратити нічого. Лічильник той самий, що й у кредитів, і обнуляється разом із циклом тарифу. Поки бюджет заданий, кожна відповідь несе X-Key-Budget-Limit і X-Key-Budget-Remaining.

2026-09-12 · Список доменів браузерного ключа тепер редагується

PATCH /v1/keys/{id} приймав тільки name. Тепер він приймає й origin_restriction, тож домен до живого pk_ ключа додається без створення другого ключа.

Що робити з вашим кодом. Нічого, якщо список ваших доменів не змінюється. Якщо ви створювали новий ключ щоразу, коли треба було додати домен, тепер досить одного PATCH: старий ключ не доводиться лишати живим “про всяк випадок”.

Новий список діє з наступного запиту, id і сам рядок ключа лишаються ті самі, після rotate список зберігається. Клас ключа не редагується: pk_ не стає server-only, секретному aw_ список не додається, порожній список теж не приймається. Усі три випадки це 400 з поясненням, а не мовчазний перезапис.

Окремо: відповідь на невідомий ключ тепер називає обидва класи, aw_ для сервера і pk_ для браузера, замість самого лише “Invalid API key”.

2026-09-11 · BaZi: увесь класичний апарат, істинний сонячний час і одна депрекація

Вісім нових шляхів. POST /v1/bazi/chart віддає карту цілком; поруч односкладові hidden-stems (藏干), na-yin, life-stages (十二長生), symbolic-stars (神煞), interactions (刑冲合害) і strength. POST /v1/chinese/true-solar-time виправляє годинник під довготу місця народження.

Там, де традиції розходяться, віддаються обидва читання, а не одне: напрям іньських стовбурів у дванадцяти стадіях, обидві позиції іньського леза, вельможа для 庚, стихія з’єднання 午未. Пороги сили названі нашою конвенцією, а не каноном.

Депрекація. elementCounts, dominantElement і missingElements у відповіді /v1/bazi/element-balance рахують тільки рік і місяць, чотири ієрогліфи з восьми, і не відкривають гілки. Вони відповідають без змін до 2027-09-08 і несуть заголовки Deprecation і Sunset. Повний рахунок живе в новому об’єкті balance.

Що робити з вашим кодом. Якщо ви читаєте elementCounts, перейдіть на balance.visible (ті самі вісім ієрогліфів як цілі числа) або balance.weighted (з розподілом прихованих стовбурів). Якщо ні, нічого: усе інше додано, нічого не змінено. Опція trueSolarTime вимагає longitude, time і timezoneOffset разом, інакше 400.

2026-09-11 · Біоритми тепер віддаються даними, а не тільки картинкою

POST /v1/render/biorhythm малював три кривих, але прочитати числа з SVG було неможливо. З’явився POST /v1/wellness/biorhythm: ті самі цикли у вигляді JSON.

Що робити з вашим кодом. Нічого, якщо вам достатньо картинки: /render/biorhythm не змінився і малює те саме. Якщо ви розбирали SVG або рахували цикли самостійно, тепер можна брати готові значення.

На кожен день у відповіді приходить значення трьох циклів у діапазоні від -1 до 1 (помножте на 100, якщо потрібні відсотки) і номер дня життя. Окремо приходить список критичних днів: це дні, коли цикл перетинає нуль, а не дні з малим значенням. День народження критичний для всіх трьох циклів одразу, бо всі вони починаються з нуля.

birthDate обов’язковий, rangeStart і rangeEnd ні: без них береться сьогодні плюс 29 днів. Діапазон включає обидві межі, максимум 366 днів, перевернутий діапазон дає 400 замість порожньої відповіді.

Метод не має доказової бази: це нумерологічна конструкція кінця XIX століття. Відповідь несе про це окреме попередження, і ми не радимо будувати на ній нічого, крім розваги.

2026-09-10 · Сім опублікованих схем відповіді описували поля, яких API не віддає

Схема відповіді в /openapi.json будується з прикладу, який ми пишемо для кожного ендпоінта. Дванадцять таких прикладів описували поля, яких API не віддає. Тепер це захоплення живої відповіді.

Самі відповіді не змінилися: помилка була в описі, а не в API.

Того ж роду було ще шістнадцять операцій, чия схема відповіді не називала жодного поля: чотирнадцять каталогів Таро, чиї приклади читалися як [...78 cards...] і не парсились узагалі, плюс /health і /version, які несли приклад без схеми. Тепер усі приклади це захоплення живих відповідей. Останні дві, POST /v1/mcp/streaming і POST /v1/mcp/tool-call-stream, порожніми були не помилково: вони віддають text/event-stream, а не JSON, і тепер спека так і каже, з описом форми кожного кадру. Генератор більше не пообіцяє вам розбірний JSON там, де приходить потік.

Що зробити з вашим кодом. Якщо ви генерували типи з /openapi.json для цих ендпоінтів, перегенеруйте: поля, які ви типізували, у відповіді ніколи не приходили, і код, що на них покладався, отримував undefined. Найчастіший випадок: ключ, створений через POST /v1/keys, читається як api_key.

2026-09-09 · Ліліт малюється на всіх західних зображеннях, і з’явився bodies

Точка Ліліт (середній апогей Місяця) поверталася у відповіді /v1/chart під іменем mean Apogee, але не потрапляла на жодне зображення: гліф і зіставлення імен існували, а списки тіл у рендерерах її не несли. Тепер вона малюється гліфом ⚸ на wheel-western, bi-wheel, tri-wheel, composite, cosmogram і aspect-grid. На трьох ведичних форматах її свідомо немає: чорний Місяць не належить джйотішу.

Постер /v1/reports/stellaforge друкував сирий підпис ефемерид, ♆ ☌ mean Apogee, у списку аспектів. Тепер там гліф.

Що робити з вашим кодом. Якщо ви хочете попередній набір тіл, попросіть його явно: options.bodies приймає список і звужує типовий набір рендерера. Попередній вигляд це ["Sun","Moon","Mercury","Venus","Mars","Jupiter","Saturn","Uranus","Neptune","Pluto","North Node","Chiron"]. Якщо поля немає, набір типовий, тож якщо ви нічого не міняєте, у вас нічого не ламається. Порожній список повертає 400, а не типовий набір: порожнім він майже завжди виходить випадково, і мовчазне повернення до типового приховало б це. Ім’я поза списком тіл, які ми вміємо малювати, теж повертає 400, а не зникає тихо.

2026-09-04 · Публічні ендпоінти: окрема квота для сайтів, які рендерять на сервері

Публічний доступ без ключа рахувався тільки за IP: 30 запитів на годину. Для браузера це правильно, бо кожен відвідувач приносить власний IP і власну квоту. Для сайту, який робить запити зі свого сервера, це не працює: одна машина ходить за всіх відвідувачів і вичерпує 30 запитів за кілька перезавантажень сторінки.

Тепер, якщо запит несе заголовок X-AstroWay-Site-URL з адресою сайту, діє інша квота: 300 запитів на годину на сайт і стеля 600 запитів на годину на IP. Без заголовка все як раніше, 30 на годину на IP.

Що робити з вашим кодом. Якщо ви ходите з браузера або вставляєте iframe-віджети /v1/embed/*, не робіть нічого: поведінка не змінилася, і квота, як і раніше, у кожного відвідувача своя. Якщо запити робить ваш сервер, додайте X-AstroWay-Site-URL: https://ваш-домен/ і кешуйте відповіді на своєму боці. Заголовок уже був дозволений у CORS, окремих налаштувань не потрібно.

Заголовок це декларація, а не облікові дані, тому стеля на IP залишається: скільки б доменів не назвали з однієї адреси, сумарно звідти піде не більше за 600 запитів на годину. Обидва лічильники потрібні одночасно: лічильник сайту спрацьовує, коли один сайт ходить з багатьох адрес (CDN, балансувальник), лічильник IP спрацьовує, коли з однієї адреси приходить багато імен.

У відповіді з’явився заголовок X-RateLimit-Scope зі значенням ip або site. Він каже, який лічильник зараз найтісніший, і решта заголовків X-RateLimit-* описують саме його.

2026-09-03 · Публічна синастрія без ключа, і планетарні години більше не брешуть про поточну годину

POST /v1/public/synastry віддає оцінку сумісності й сітку кросаспектів для двох карт народження без ключа. Відповідь навмисно маленька:

{ "score": 68, "label": "harmonious",
  "aspects": [{ "planetA": "Pluto", "planetB": "Saturn", "aspect": "Square", "orb": 0.0509, "applying": false }],
  "count": 45 }

Аспекти відсортовані за орбом, найточніші перші, тож перші шість це ті самі шість, які показує віджет. За ключем лишається все інше, що віддає автентифікований POST /v1/synastry: тлумачення кожного аспекту, накладення по домах, композит і Davison, і самі дві натальні карти.

Виклик коштує 3 одиниці публічної корзини, а не 1. Це дві карти й матриця на 45 клітинок, тому рахувати його як фазу Місяця було б неправильно. Ліміти ті самі: 10 таких викликів на годину з незаявленої адреси, 100 на заявлений сайт, 200 на адресу. Відповідь несе заголовок X-RateLimit-Cost: 3.

POST /v1/planetary-hours: поле isCurrent більше не приходить порожньою обіцянкою. Воно публікувалося на всіх 24 годинах і на всіх 24 було false, бо роут ніколи не передавав рушію поточну годину. Тепер її передає той, хто питає: надішліть atLocalHour (десяткові години місцевого часу, наприклад 15.2), і година, що містить цей момент, отримає isCurrent: true. Без цього поля немає взагалі: відповідь кешується, і прапорець з годинника сервера все одно був би застарілим на момент рендеру.

Полярний день і полярна ніч більше не повертають 24 порожні години. Раніше відповідь казала, що планетарні години не визначені, і все одно віддавала таблицю, де всі проміжки нульові. Тепер hours порожній, а sunTimes.warning пояснює чому. Значення sunTimes.polarState описані в схемі: normal, polar-day, polar-night.

Що зробити з вашим кодом. Якщо ви читали isCurrent, він у вас завжди був false: додайте atLocalHour до запиту або рахуйте поточну годину самі з startHour і endHour. Якщо ви малюєте таблицю годин, перевірте порожній масив для полярних широт.

2026-08-31 · Аянамса тепер приймається за назвою, і десять сторінок документації виправлено

Ведичні ендпоінти завжди читали числовий ayanamsaId. Документація при цьому показувала "ayanamsa": "lahiri" на десятку сторінок, а схема була passthrough, тому рядок проходив валідацію і мовчки ігнорувався: відповідь рахувалась по Lahiri, що б ви не надіслали. Перевірено на /v1/vedic/dashas/vimshottari/maha: "lahiri" і "raman" давали ту саму сидеричну довготу Місяця, тоді як ayanamsaId 1 і 3 дають різні накшатри.

Тепер назва працює. Приймаються fagan-bradley, lahiri, de-luce, raman, krishnamurti (він же kp), yukteshwar, jn-bhasin, true-citra, djwhal-khul. Явний ayanamsaId має пріоритет, якщо надіслані обидва. Невідома назва тепер повертає 400 INVALID_FIELD зі списком допустимих замість того, щоб тихо відпрацювати по Lahiri. Обидва поля описані в /v1/openapi.json, тож потраплять у згенеровані клієнти.

Що зробити з кодом. Якщо ви надсилали ayanamsa з назвою, відмінною від lahiri, ваші відповіді досі рахувались по Lahiri, а тепер рахуватимуться по обраній школі: числа зміняться. Якщо надсилали назву поза списком вище, запит почне повертати 400.

Окремо виправлено десять сторінок документації, приклади на яких не працювали: POST /v1/keys приймає name, а не label; /v1/horoscope/daily це sign + date + language, а не натальна карта; /v1/transit-calendar чекає дані народження всередині natal; /v1/vedic/muhurat/* приймає search_window_start / search_window_end / topN. Ендпоінтів /v1/interpret/aspects і /v1/vedic/vargas не існує: замість другого є окремий шлях на кожну варгу, наприклад /v1/vedic/varga/D9.

Ще дві сторінки радили передавати zodiac=tropical заради тропічного Vedic. Такого поля немає, а ведичні ендпоінти в будь-якому разі рахують сайдерично і zodiacType у тілі ігнорують. Якщо ви це надсилали, воно нічого не робило; тропічні позиції дає західна гілка (/v1/chart).

2026-08-28 · Параметри запиту, які раніше не перевірялися, тепер описані й валідуються

Шість ендпоінтів читали поле, якого не було в їхній схемі. Таке поле не перевірялося й не потрапляло до /openapi.json, тож ішло в розрахунок як є і ламало відповідь трьома різними способами, і завжди під статусом 200.

Що робити з вашим кодом. Якщо ви надсилали коректні значення, не робіть нічого: поведінка не змінилася, числові рядки так само приводяться до чисел. Якщо ви надсилали щось некоректне, тепер прийде 400 з INVALID_INPUT замість тихо зіпсованої відповіді. Нові параметри тепер описані у /openapi.json, тож вони з’являться у SDK і MCP після наступної регенерації.

orb у /v1/parallel-aspects і /v1/midpoint-trees був найнебезпечнішим: нечислове значення робило хибним кожне порівняння, і замість шести аспектів чи десяти дерев поверталася порожня відповідь. Порожній масив читається як “нічого не знайдено”, а не як “поганий запит”, тож помітити це на своєму боці було неможливо.

targetDate у /v1/vedic/jaimini/dasha-summary і /v1/vedic/doshas/kp/sade-sati повертав усі даші як null. key і maxAge у /v1/primary-directions тихо псували вибірку: key тут це швидкість у градусах на рік, а не назва режиму, і тепер це число з межами.

Друга хвиля закрила клас повністю. parts у /v1/arabic-parts і maxYears у /v1/firdaria так само віддавали порожній результат замість 20 жеребів і 63 періодів. termsData і decansData у /v1/almuten, /v1/essential-dignities, /v1/hyleg і /v1/receptions роняли обробник у 500. /v1/hd/incarnation-cross узагалі не перевіряв номери воріт, а /v1/human-design/transits брав натальну дату, якої не було в схемі, і накладав транзити на хибну карту, і відповідь при цьому виглядала звичайною.

2026-08-27 · Специфікація тепер описує кожне тіло запиту й відповіді публічних роутів

/v1/openapi.json віддавав для 246 шляхів порожнє тіло запиту: {"type": "object"} без жодного поля. Ендпоінти працювали й перевіряли вхід як завжди, але специфікація про цей вхід не казала нічого, тому згенерований із неї клієнт не мав типу для запиту, а агент, який читає схему, не бачив назв полів. Тепер таких шляхів нуль.

Найбільші групи: нумерологія (50 шляхів), таро (47), китайський блок (14), тварини (14), варги (16), дзи-вей (13), бізнес (11), базі (11), фінанси (10), велнес (9), майя (8). Двадцять шість шляхів, чиї обробники не читають тіло взагалі (16 фігур геомантії, 5 ліній хіромантії, чотири стріми, каталог рун), тепер посилаються на EmptyBody: раніше специфікація казала “тіло може бути будь-яким”, тепер каже правду - його немає.

PATCH і PUT не мали тіла в специфікації взагалі. Генератор описував його тільки для POST, тому PATCH /v1/whitelabel/config не публікував нічого, хоча роут перевіряє кожен виклик. Тепер у нього є схема.

Вісім публічних роутів не мали схеми відповіді. По всій специфікації її мали 733 операції з 758, а без неї лишалися саме ті, які читають server-side без ключа: POST /v1/public/chart, POST /v1/public/human-design, три гороскопи, GET /v1/public/tarot/daily, /moon-phase і /planet-of-day. Тепер кожна віддає ok, data і _footer з полями всередині; обидва POST беруть схему в свого автентифікованого двійника, тож поле, додане в /v1/chart, не може зникнути з /v1/public/chart.

Заразом виправлені надруковані приклади, які були неправильні: у публічному таро position і card показувалися рядками, хоча це об’єкти, а /public/moon-phase і /public/planet-of-day не показували localized взагалі. Приклади /v1/chart і /v1/human-design не містили семи й шести полів верхнього рівня відповідно, а channels був надрукований у формі, якої рушій ніколи не повертав.

Що зробити з вашим кодом. Нічого, якщо ви пишете запити руками: жодне поле не перейменоване, не додане й не прибране, валідація та сама. Якщо ви генеруєте клієнт зі специфікації, перегенеруйте його: там, де раніше було unknown, тепер тип із полями, і публічні відповіді теж типізовані.

2026-08-24 · Документація ведичної сумісності виправлена, тіло запиту це chart1/chart2

Сторінка /vedic/compatibility/ показувала тіло запиту з полями person1 і person2. Жоден із шести ендпоінтів ніколи їх не приймав: схема весь час вимагала chart1 і chart2, тому кожен приклад із тієї сторінки повертав 400 INVALID_INPUT. Сама схема не змінювалась, змінилась документація.

Що ще було неточним на тій сторінці і тепер відповідає реальності:

• /vedic/compatibility/full повертає data.manglik.partner1, partner2 і verdict. Ключів person1.present, cancelled і bhrigu там немає, Bhrigu-Bindu це окремий ендпоінт /bhrigu-match.
• Відповідь /ashtakoot має вигляд data.{method, school, boy, girl, total, max, threshold, points{}, doshas[], recommendation}. Полів passing_threshold, verdict, breakdown[] і warnings[] не існує.
• Вартість: mangal-match, bhrigu-match і full це 50 кредитів кожен, а не 20, 30 і 100. Ціни не змінювались, у таблиці були неправильні числа.

Приклади на сторінці тепер запущені проти продакшна, а відповідь у JSON це дослівний захват для тієї самої пари, що в запиті вище.

2026-08-22 · Повтор запиту з кешу більше не списує кредити

Ми пишемо на сторінці вартості і в конвенціях, що відповідь із заголовком X-Cache: HIT не коштує кредитів. Насправді вона коштувала повну ціну: списання відбувається до кешу, і нічого його не скасовувало. Перевірено трьома однаковими викликами /v1/acg/by-category: два з них повернули X-Cache: HIT, і баланс щоразу зменшувався на 50.

Тепер повтор ідентичного запиту протягом 5 хвилин коштує 0, а X-Credits-Used і X-Credits-Remaining у відповіді показують це чесно.

Той самий запит іншою мовою міг повернути чужу мову. Ключ кешу враховував ?lang=, бо той їде в query, але не враховував заголовок Accept-Language. Два клієнти на одному тарифі з однаковим тілом і різними мовами ділили один запис. Запит із Accept-Language: de повертав українську відповідь, у якій ще й було написано requestedLanguage: "uk". Мова тепер входить у ключ.

/v1/interpret/* більше не проходить через цей кеш. У нього є власний AI-кеш із годинним TTL і 50% знижкою на повтор, і саме він мав відповідати, але список винятків містив interpret замість interpret/*, тому першим завжди спрацьовував загальний. /v1/horoscope/* навпаки залишається тут: його обробник звертається до моделі на кожен запит, і цей кеш - єдине, що стоїть між повтором і другою генерацією.

Що зробити з вашим кодом. Нічого. Якщо ви обходили кеш, додаючи в тіло щось випадкове, щоб не платити двічі за ту саму відповідь, тепер це не потрібно.

2026-08-22 · Ціни в кредитах на кількох сторінках були надруковані неправильно

Таблиці “Кредити” в документації називали одні числа, а списувалися інші. Жодна ціна не змінилася: неправильним був друкований бік. Точна вартість завжди була і залишається в X-Credits-Used кожної відповіді та на сторінці Вартість ендпоінта, яка будується прямо з тарифної таблиці.

Де було дорожче, ніж написано. Це той бік, який б’є по бюджету:

Зворотний бік теж є: доші Лал Кітаб і КП, йоги Джайміні та частина дашів коштують 10, а не 20-100, як було написано.

Що зробити з вашим кодом. Перерахувати бюджет кредитів, якщо ви планували його за цими сторінками, і звірити з X-Credits-Used у власних логах. Викликів міняти не треба.

Вісімнадцять шляхів у тих самих таблицях ніколи не існували. Якщо у вашому коді є хоч один із них, він повертає 404 сьогодні і повертав завжди: усі /v1/vedic/doshas/jaimini/*, /v1/vedic/doshas/all, /v1/vedic/muhurat/engagement, /griha-pravesh, /court-case, /v1/vedic/yogas/jaimini/atmakaraka, /badhaka. Три були опискою в назві і тепер виправлені: /v1/vedic/doshas/kp/mangal це kp/manglik, /v1/vedic/doshas/lal-kitab/kaal-sarp це lal-kitab/kalsarpa, /v1/vedic/panchang/nakshatra це panchang/nakshatra-of-day.

Варги ніколи не приймали levels. Сторінка обіцяла один виклик /v1/vedic/vargas з масивом рівнів; такого шляху немає. Кожна ділена карта це свій шлях, /v1/vedic/varga/D9 і решта, по 20 кредитів за карту.

Кожна цифра в документації тепер звіряється з тарифною таблицею механічно, на кожен коміт.

2026-08-21 · Символічні дирекції: ключ дуги тепер перевіряється, solar arc рахує

POST /v1/symbolic-directions приймає параметр key із трьома значеннями: one_degree (за замовчуванням, 1° на рік), naibod (59’08.3” на рік) і solar_arc (дуга прогресованого Сонця). Раніше параметр не був описаний у схемі й потрапляв у розрахунок як є, тому будь-яке значення, окрім naibod, давало null у всіх довготах, куспідах, асценденті та в самій дузі, і все це під статусом 200.

Що робити з вашим кодом. Якщо ви надсилали key: "solar_arc" чи key: "one_degree" і отримували null, тепер приходять числа: нічого міняти не треба, відповідь просто стала осмисленою. Якщо ви надсилали будь-яке інше значення, тепер повертається 400 з INVALID_INPUT замість тихого null. У відповідь додано поле key, яке повертає застосований ключ.

solar_arc рахується як дуга, пройдена прогресованим Сонцем (день за рік), тож для народженого в травні вона трохи менша за градус на рік: 34.51° проти 36.00° за 36 років. Конверсні дирекції (converse: true) обертають знак дуги один раз.

2026-08-17 · Планетарні години й час сходу виправлені для половини часових поясів

POST /v1/planetary-hours і POST /v1/sun-times повертали неправильні значення скрізь, де місцева доба не збігається з добою UT. Година сходу бралася всередині доби UT і до неї додавався зсув без приведення до доби, тому Сеул віддавав riseHour 29.81, а Лос-Анджелес setHour -4.36. Тривалість денної години рахується як (setHour - riseHour) / 12, тож вона виходила відʼємною, і таблиця з 24 годин ішла назад у часі.

Кого це зачепило. Уся Східна Азія й Океанія, Делі біля сонцестояння, вечір обох Америк. Київ і Європа рахувалися правильно і до, і після.

Що зробити з вашим кодом. Нічого міняти не треба, контракт той самий. Але якщо ви кешували відповіді /planetary-hours або /sun-times для цих регіонів, заберіть їх заново: збережене значення неправильне.

Перевірено проти api.sunrise-sunset.org на Сеулі, Токіо, Лос-Анджелесі й Окленді: розбіжність 1-2 хвилини, вона систематична й була там і до виправлення.

Разом з цим: tzOffset у тілі запиту тепер відхиляється з 400 INVALID_FIELD і підказкою. Раніше таке поле мовчки ігнорувалося, зсув ставав нулем, і карта рахувалася для UTC без жодної ознаки, що щось не так. Правильна назва поля залишається timezoneOffset.

2026-08-14 · Астрокартографія: сфери життя та інтерпретації ліній

Три нових ендпоінти перетворюють геометрію /v1/acg на відповідь про місце. GET /v1/acg/categories віддає таксономію з 19 сфер життя (кар’єра, кохання, гроші, здоров’я, дім, навчання, вплив, подорожі та інші): кожна називає свої лінії планета-кут із вагою 1-3 і полярністю. Безкоштовно, кешуйте на своєму боці.

POST /v1/acg/by-category повертає лінії однієї сфери, відранжовані за вагою, а якщо передати point, то й за близькістю до нього (strength = вага × близькість, плюс distanceDeg). Tier 3. POST /v1/acg/line-report віддає одну лінію повністю: геометрію, всі сфери, яких вона торкається, і текст інтерпретації. Tier 2. Геометрія приходить як segments, масив полілиній: крива сходу чи заходу складається з кількох роз’єднаних відрізків, і повертаються всі.

Текст подається з кураторської бази знань 11 мовами (language, відкіт en → uk, реально віддана мова повертається в полі lang), а не з мовної моделі: відповіді детерміновані. Складні лінії повертаються поруч зі сприятливими; фільтруйте через polarity, якщо потрібні лише одні. Деталі: Інтерпретації астрокартографії.

Разом із цим виправлено довідник: описи /parans, /local-space, /solar-acg, /acg-zones і /zenith розходилися з фактичними відповідями. Самі ендпоінти не змінювалися, змінилася лише документація до них.

2026-08-13 · POST /v1/reports/relocation, до п’яти місць в одному PDF

Що робити з вашим кодом. Нічого, якщо ви не будували релокаційний документ самі. Якщо будували, склеюючи /v1/relocation з /v1/acg-zones для кожного міста, тепер це один виклик, і він повертає готовий PDF або HTML з ?format=html. Тариф Tier 7, 5000 кредитів.

У тілі: chart, масив locations від одного до п’яти елементів, кожен із координатами, і необов’язкові categories, orbKm, language, whitelabel. Координати обов’язкові для кожного місця й нулями не підставляються: звіт, збудований на 0N 0E, це впевнений документ про Гвінейську затоку, а PDF, на відміну від поля в JSON, залишається у клієнта.

Для кожного місця документ дає релокаційні асцендент і середину неба зі знаковим зсувом від народження, перелік планет, які змінили дім (це і є суть релокації, зведена різницею, а не двома таблицями), кожну астрокартографічну лінію в межах 300 км разом із текстом тлумачення, і бали по сферах життя. Коли місць більше одного, документ відкривається таблицею порівняння.

Свідомо без AI-розповіді й без колеса карти. Колесо релокаційної карти показує ті самі планети в повернутій рамці й читається як друга карта, а це якраз те непорозуміння, яке звіт знімає першим абзацом; розповідь про місце була б порадою, де жити.

2026-08-12 · Горизонтні лінії астрокартографії виправлено, приберіть обхід

Що робити з вашим кодом. Якщо за записом нижче ви поміняли ASC і DSC місцями у себе, приберіть цей обхід: інакше ви знову читаєте не ту половину. Якщо ви читали поле knownDefect, його більше немає у відповідях /v1/acg, /v1/acg-zones, /v1/acg/by-category, /v1/acg/line-report, /v1/parans і /v1/solar-acg. Якщо ви не встигли нічого змінити, робити нічого не треба.

Змінились не лише мітки, а й координати. Стара формула розв’язувала горизонтну криву через екліптичну довготу і не враховувала екліптичну широту тіла, тому лінія відхилялась приблизно на 103 км за кожен градус цієї широти. Для Сонця і вузлів це нуль, для Місяця сотні кілометрів, а для тіла, що стоїть високо над екліптикою, понад 1500 км. Тепер обидві половини рахуються з рівняння горизонту в екваторіальних координатах, як і MC з IC.

Практичний наслідок: кешовані карти й збережені координати ліній варто перебудувати, інакше вони розійдуться з новими відповідями. Парани (/v1/parans) зсунулись услід за лініями. POST /v1/acg/best-places і POST /v1/parans/star не змінились: вони від початку рахували власну геометрію з прямого сходження і схилення, і саме розбіжність із ними виявила помилку.

Перевірка, яку тепер видно на сторінці точності: береться кожна точка кожної горизонтної кривої і рахується висота тіла над горизонтом у ній. На 8419 точках максимальне відхилення нульове.

2026-08-12 · На горизонтних лініях астрокартографії мітки ASC і DSC поміняні місцями

Що робити з вашим кодом. Якщо ви розрізняєте ASC і DSC у відповідях астрокартографічних ендпоінтів, поміняйте їх місцями у себе: те, що ми позначаємо ASC, це захід, а DSC це схід. Перераховувати нічого не треба, переставлені саме мітки, а не геометрія. Якщо ви працюєте лише з MC та IC або взагалі не дивитесь на тип лінії, робити нічого не треба.

Зачеплені /v1/acg, /v1/acg-zones, /v1/acg/by-category, /v1/acg/line-report, /v1/parans і /v1/solar-acg. Кожен із них із цього дня повертає у тілі відповіді поле knownDefect зі стабільним id acg-horizon-labels-inverted, описом і способом обійти. Поле лежить усередині data, а не поруч із ним, тому воно переживає розпакування конверта, яке роблять наші SDK. Воно зникне разом із дефектом, тож не покладайтесь на його присутність назавжди.

MC та IC коректні: вони рахуються з прямого сходження окремо. POST /v1/acg/best-places теж коректний, він рахує власну геометрію з годинного кута і схилення. Там, де best-places розходиться з /acg/by-category на горизонтних лініях, має рацію best-places.

Окремо попереджаємо про тлумачення: текст у /acg/by-category і /acg/line-report обирається за парою (планета, кут), тому разом із міткою він теж стосується протилежної половини кривої.

Знайдено 2026-08-05 під час звірки двох наших власних ендпоінтів між собою. Виправлення належить спільному ядру розрахунків і готується; цей запис оновиться, коли воно приїде.

2026-08-10 · @astroway/sdk 1.5.1, приклад зі швидкого старту тепер працює

Що робити з вашим кодом. Нічого, якщо ви не копіювали швидкий старт із README. Якщо копіювали, виправте: chart.angles.asc не існує.

У відповіді /chart немає ключа angles. Асцендент лежить у chart.houses.ascendant і є екліптичною довготою в градусах, а не назвою знака: /chart взагалі не повертає готових підписів. Тобто перший же виклик, який копіював новий інтегратор, падав із TypeError. У README тепер робочий приклад із виведенням знака з довготи (Math.floor(longitude / 30)), і кожен приклад із змінених розділів прогнано проти продакшена перед тим, як його записали.

Заодно в розділі про помилки описано 400 INVALID_FIELD: короткі імена координат у тілі відхиляються, а details називає всі проблемні поля за раз.

2026-08-10 · astroway 1.4.1 (Python), приклад зі швидкого старту тепер працює

Що робити з вашим кодом. Нічого, якщо ви не копіювали швидкий старт із README. Якщо копіювали, виправте: chart["angles"]["asc"] кидає KeyError.

Ключа angles у відповіді /chart немає. Асцендент це chart["houses"]["ascendant"], екліптична довгота в градусах, а не назва знака. Той самий рядок був і в асинхронному прикладі, виправлено обидва. Розділ про помилки отримав опис 400 INVALID_FIELD із масивом details.

2026-08-10 · astroway/sdk 1.4.1 (PHP), приклад зі швидкого старту тепер працює

Що робити з вашим кодом. Нічого, якщо ви не копіювали швидкий старт із README. Якщо копіювали, виправте: $chart['angles']['asc'] це неіснуючий ключ.

Асцендент лежить у $chart['houses']['ascendant'] і є екліптичною довготою в градусах. Розділ про помилки отримав опис 400 INVALID_FIELD; зверніть увагу, що код помилки читається як $e->errorCode, бо $e->code зайнятий базовим \Exception.

2026-08-10 · Короткі імена координат відхиляються, і тепер помилка називає всі поля одразу

Що робити з вашим кодом. Якщо ви надсилаєте lat, lon, lng, long, tz, timezone, timeZone чи time_zone у тілі chart-запиту, перейменуйте їх на latitude, longitude і timezoneOffset. Якщо ви вже надсилаєте повні імена, робити нічого не треба. Швидка перевірка: grep по вашому коду на "lat" і "tz" у тілах запитів.

Відхилення діє з 2026-08-01, і це не депрекація. Короткі імена ніколи не були в контракті й не фігурували в /openapi.json як поля тіла. Вони не працювали, а мовчки ігнорувалися: координати мають типовий нуль, тому карта рахувалася для 0°N 0°E за UTC. Асцендент, доми і все похідне від них поверталися неправильними, і у відповіді не було нічого, що б на це вказувало. Ми не приймаємо ці форми назад: це два імені на одне поле назавжди, а tz до того ж неоднозначний, бо ним шлють і число, і назву зони.

Сьогодні виправлено сам формат відмови. Раніше відповідь називала лише одне поле за раз, тож тіло з трьома короткими іменами вимагало трьох підходів. Тепер 400 INVALID_FIELD перелічує всі знайдені поля за один раз у порядку тіла, додає details з { path, expected, message } по кожному (той самий масив, що вже є в INVALID_INPUT) і посилання на розділ документації. path містить повний шлях, тому в synastry видно, чия саме карта: chart1.lat. Код розписано в Помилки.

Вкладений point: { lat, lng } у /v1/acg-zones, /v1/acg/by-category, /v1/ccg-analysis і /v1/eclipse-analysis не зачеплено: там це задекларовані імена полів.

Заразом виправлено опис ChartInput у /openapi.json, який називав короткі імена й описував нульові координати як прийнятний типовий варіант. Це зачіпає 31 схему, а разом з ними згенеровані типи в SDK і описи інструментів MCP. Якщо ваш код або ваш агент будувалися за старим описом, звіртеся з новим.

latitude і longitude стають обов’язковими з 2026-11-09

Та сама пастка з іншого боку. Координати мали типовий нуль, тому тіло без них теж отримувало 200 з картою для 0°N 0°E: доми, кути й усе похідне рахувалися там, і у відповіді не було нічого, що б на це вказувало.

Що робити з вашим кодом. Якщо ви надсилаєте latitude і longitude, нічого. Якщо не надсилаєте, додайте їх до 2026-11-09.

До 2026-11-09 нічого не ламається. Запит без координат далі працює, але перестає бути тихим: відповідь несе заголовки Deprecation, Sunset, Warning і поле _warning у тілі, яке прямо каже, що місце вигадане. З 2026-11-09 таке тіло отримає 400 з назвою відсутнього поля. Ми дали 90 днів, а не звичні 12 місяців стабільності /v1: тут не знімається робоча можливість, тут припиняється видача неправильної відповіді.

Явні latitude: 0, longitude: 0 лишаються валідними. Питання у відсутньому полі, а не в значенні: хто справді має на увазі Гвінейську затоку, той так і пише.

timezoneOffset типовий нуль зберігає: там нуль означає UTC, реальне значення. І врахуйте, що city це підпис, а не вхідні дані: жоден ендпоінт його не геокодує, тому він ніколи не замінює координати.

Заодно широта поза ±90 і довгота поза ±180 тепер відхиляються. Раніше проходили.

2026-08-09 · POST /v1/ziwei/four-transformations, 四化 за роками, з усіма версіями шкіл

Новий ендпоінт віддає чотири зірки, які активує небесний стовбур року народження: 化禄 (достаток), 化权 (влада), 化科 (визнання), 化忌 (перешкода). Це єдина частина Цзи Вей, яку можна порахувати без розміщення зірок по палацах, бо вона залежить лише від стовбура року.

Стовбур береться з точної миті Лічуня, тож народження в день межі дає різні зірки залежно від години. 3 лютого 2025 опівдні це стовбур 甲 і 廉贞 у 化禄, а о 23:59 вже 乙 і 天机.

Головне: там, де традиції не згодні, ми віддаємо всі версії. Сім стовбурів із десяти читаються однаково в усіх переданнях, які ми звіряли. Три (戊, 庚, 壬) розходяться, і для них відповідь містить schoolVariants з читанням кожної школи, а поле disputed це позначає. Стовбур 庚 зсуває не лише 化科, а й 化忌, тобто ігнорування питання школи змінює зірку перешкоди, а не просто зірку визнання.

За замовчуванням ми йдемо за 中州派. Параметр school перемикає на quanji, quanshu або beipai. Якщо звіряєтеся зі звичайним онлайн-калькулятором, беріть quanji: більшість із них возять саме цю таблицю. Tier 1.

2026-08-08 · /v1/status приймає ключ у заголовку, параметр ?key= застарів

GET /v1/status тепер читає ключ із заголовка X-Api-Key. Параметр ?key= далі працює, але позначений застарілим: відповіді на нього несуть заголовки Deprecation і Warning.

Що робити з вашим кодом. Перенесіть ключ зі стрічки запиту в заголовок:

curl -H "X-Api-Key: aw_live_ваш_ключ" https://api.astroway.info/v1/status

Причина не косметична. URL потрапляє в журнали веб-сервера, у журнали CDN і в історію браузера, тому ключ, переданий у стрічці запиту, перестає бути таємницею. Значення ключів у наших журналах відтепер приховуються, але записане раніше вже записане.

Дату вимкнення параметра оголосимо окремо, не менш ніж за 90 днів наперед.

2026-08-07 · Stellaforge: постер натальної карти (/v1/reports/stellaforge)

Новий ендпоінт рендерить готовий до друку постер натальної карти - кольорове колесо (сектори стихій, градусні підписи, стрілка ASC, маркер MC, доми), велика трійка Сонце/Місяць/Асцендент, таблиця планет, баланс стихій і модальностей, ключові аспекти. Повністю детерміновано, 0 AI. Tier 7.

Три стилі через style: editorial (світлий), celestial (темний + золото), classic (мінімалістичний). PDF за замовчуванням, ?format=html віддає HTML. Підтримує white-label і багатомовність. NB: style читається з тіла запиту, не з query-string. Деталі - Stellaforge.

2026-07-31 · /v1/match/score, dating-сумісність одним викликом

Новий ендпоінт для застосунків знайомств: повертає сумісність одним запитом замість окремих synastry + attraction + власної логіки прапорців. Tier 3. Той самий вхід chart1 + chart2, що й /synastry.

Повертає score (0-100) + label + harmony/tension + attraction (окремий скор) + topAspects (з tone) + greenFlags/redFlags. Числа ідентичні /synastry + /synastry/attraction-score - це переформатований вивід того самого рушія, не нова модель скорингу. Деталі - Dating & Compatibility API.

2026-07-28 · Китайський календар рахується з ефемерид: точні цзєці, місячні місяці, локальний час для дня і години

Межі китайського сонячного року і місяця більше не беруться з таблиці календарних дат. Тепер це фактичні миті: сонячний термін це момент, коли видима довгота Сонця досягає кратної 15°, а місячний місяць починається пекінського дня, на який припадає молодик.

Це виправляє відповіді, а не лише формулювання. Лічунь (立春) припадає будь-коли на 3-5 лютого і о будь-якій годині: 2026 року о 04:02 за Пекіном, 2025 року взагалі 3 лютого. Старе правило “до 4 лютого” відносило всі народження того дня до одного відра. Народження 2025-02-03 тепер повертає Jia-Chen (Дракон) опівдні та Yi-Si (Змія) о 23:59, як і має бути. Те саме дванадцять разів на рік на межах місяців. Якщо ви кешували відповіді /bazi/* або /chinese/* для дат поблизу 3-5 лютого чи початку будь-якого місяця, перерахуйте їх.

Усі ендпоінти /bazi/* та /chinese/* тепер приймають необов’язкові time і timezoneOffset. Саме вони вирішують відповідь біля межі; без них календар припускає пекінський полудень. Межі завжди рахуються за китайським стандартним часом, незалежно від того, де народилася людина.

Заодно виправлено дві помилки. /v1/bazi/luck-pillars брав стовбур року з григоріанського року замість сонячного, через що для січневих народжень послідовність ішла у зворотний бік. /v1/chinese/zodiac/inner-animal зіставляв номер григоріанського місяця з гілкою напряму, тож кожна відповідь була зсунута на одну позицію: середина червня давала Козу там, де місяць Wu дає Коня.

Два нові ендпоінти. POST /v1/chinese/solar-terms віддає 24 терміни року як точні миті в UTC і за Пекіном, з позначкою, які з них відкривають стовп місяця. POST /v1/chinese/lunar-date перетворює григоріанську дату на місячну, включно з визначенням високосного місяця, і повертає дату Нового року. Обидва Tier 1.

День і година тепер рахуються за місцевим часом народження. Гілка години бралася від пекінського еквівалента години народження, тоді як дата лишалася місцевою. Через це /v1/bazi/hour-pillar і /v1/bazi/four-pillars віддавали різні стовпи години для одного народження, а день для timezoneOffset: 3 переходив на наступний о 18:00 замість 23:00. Тепер день і година йдуть за годинником місця народження (гілка Zi відкриває день о 23:00 місцевого), а рік і місяць залишаються прив’язаними до митей Лічуня і цзє. Якщо ви кешували /bazi/* для народжень поза UTC+8, перерахуйте їх. У відповіді /v1/bazi/hour-pillar з’явилося поле localHour; cstHour лишається на місці.

POST /v1/bazi/luck-pillars тепер рахує справжній вік початку (起運), а не рівні десять років. Відстань від народження до межового цзє переводиться у вік із розрахунку три дні на рік життя, тож ageStart першого стовпа більше не дорівнює 10. Додано поля startAge (роки і місяці) та startReference (який саме термін узято за межу).

Час у запитах до /bazi/*, /chinese/*, /ziwei/* тепер валідується. Значення на кшталт 99:99:99 чи 23:60:00 раніше переносилися на наступну добу, і відповідь описувала не ту дату, яку ви надіслали, а ту, куди її знесло. Тепер це 400. 24:00:00 як опівніч, що завершує добу, лишається дозволеним. Ті самі перевірки додано у /v1/compat/full, /v1/compat/astro-chinese, /v1/profile/spiritual-path і /v1/profile/multi-archetype, які вплітають китайський шар.

POST /v1/chinese/solar-terms приймає роки 2-2899 замість колишніх 1900-2100: це та сама межа, що й у решти китайських ендпоінтів.

Найважливіше: виправлено якір денного стовпа. Точка відліку шістдесятиденного циклу була зсунута на 29 позицій: код вважав, що 1990-01-01 це Yi-Wei, тоді як це Bing-Yin. Через це кожен денний стовп був неправильний, а разом із ним day master, стовбур години і всі десять божеств. Зачеплені /v1/bazi/four-pillars, /v1/bazi/day-master, /v1/bazi/hour-pillar, /v1/bazi/ten-gods, а також натальний day master у /v1/bazi/yearly і /v1/bazi/monthly. Рік, місяць і люк-пілари не зачеплені. Якщо ви зберігали будь-які відповіді /bazi/*, перерахуйте їх повністю. Перевірити просто: 1949-10-01 це 甲子, 2000-01-01 це 戊午, 2024-02-10 це 甲辰.

POST /v1/chinese/lunar-date віддавав неіснуючий тридцятий день у місяці з двадцяти дев’яти, з’їдаючи перший день одинадцятого місяця. Приблизно 72 дати між 1900 і 2100, кінець листопада і початок грудня: 2021-12-04 повертав “month 10, day 30”, хоча той самий ендпоінт повідомляв, що одинадцятий місяць починається саме 2021-12-04. Виправлено, звірено день за днем на 73 414 датах.

До 1929 року календар тепер рахується за пекінським місцевим середнім часом (UTC+7:45:40), як це й було історично, а не за UTC+8. Це зсуває три місяці до 1929 року, зокрема Новий рік 1916 повертається на історичне 3 лютого. Молодик, що припадає на кілька хвилин від місцевої півночі, все одно може розійтися з друкованим альманахом того часу на добу: ті таблиці рахувалися з точністю свого століття. Застереження є у відповіді ендпоінта.

Чотири ендпоінти, що вплітають китайський шар (/v1/compat/full, /v1/compat/astro-chinese, /v1/profile/spiritual-path, /v1/profile/multi-archetype), тепер враховують годину і часовий пояс при визначенні тварини, а не лише дату.

2026-07-27 · Zi Wei Dou Shu: виправлено довідник 14 головних зірок

POST /v1/ziwei/main-stars віддавав 14 записів, з яких унікальних було 13: зірка 太阳 (Tai Yang) дублювалася під назвами “Sun” і “Sun God”, а 巨门 (Ju Men, Giant Gate) була відсутня зовсім. Тепер у відповіді всі 14 канонічних зірок.

Виправлено назви та романізацію. 天府 має піньїнь Tian Fu (був Tian Hou, а це 天后, інше божество); 武曲 стала Martial Melody (був Big Dipper, тобто 北斗七星, сузір’я); 天梁 стала Heavenly Beam (був Heavenly Mansion, який належить 天府); 廉贞 стала Chastity (був Distinguished Stars); 天同 стала Heavenly Unity. У палацах: 疾厄宫 має піньїнь Ji'e (був Jie'e), а палац друзів тепер канонічний 仆役宫 з піньїнем Puyi (був розмовний 朋友宫 / Pengyou).

Порядок масиву змінено на канонічний: спершу шість зірок ряду 紫微, потім вісім ряду 天府. Додано поле series. Якщо ви зіставляли зірки за англійською назвою або за індексом у масиві, зіставлення зламається. Найстабільніший ключ це chinese: він не змінився в жодної зірки, крім доданої 巨门.

Поле disclaimer у відповідях /ziwei/* тепер прямо каже те, що раніше лишалося тільки в коментарі до коду: таблиці палаців і зірок статичні, вони не залежать від дати народження, з неї виводяться лише solarYear та animal. Розміщення зірок по палацах поки не реалізоване.

2026-07-24 · Muhurta API: каталог активностей + звіт сприятливих дат

Два нові ендпоінти поверх наявних /v1/vedic/muhurat/*:

• GET /v1/muhurta/types: каталог 12 активностей (ключ + санскрит + опис), безкоштовно
• POST /v1/reports/muhurta: готовий звіт сприятливих дат (PDF за замовчуванням, ?format=html), Tier 7

Що зробити: для підбору дати під подію - оберіть активність із /muhurta/types, скануйте вікно через /vedic/muhurat/{activity} (JSON) або одразу отримайте готовий звіт через /reports/muhurta. Деталі - Muhurta API.

2026-07-17 · Cosmic Notifications: вебхуки /webhooks/* тепер спрацьовують автоматично

Зареєстровані вебхуки на космічні події тепер доставляються автоматично - раніше підписка створювалась, але нічого не надсилала. Live-події (глобальні, без натальних даних): retrograde-start, retrograde-end, sign-ingress, void-of-course-start, eclipse-alert (за 7 днів до затемнення).

Що зробити: якщо ви реєстрували /v1/webhooks/<подія> - переконайтесь, що ваш endpoint приймає POST із заголовком X-AstroWay-Signature: sha256=<hmac> і звіряє підпис (HMAC-SHA256(signing_secret, raw_body)). Доставка події не тарифікується; підписка авто-відключається після 5 поспіль невдалих доставок. Деталі - Cosmic Notifications.

2026-07-11 · Vedic-ендпоінти: сидеричний лагна + локальний час у дашах

Всі ведичні ендпоінти, що спираються на лагну, рахували її від тропічного асценденту, хоча планети вже були сидеричними: дивізіональні карти (/vedic/varga/*), доші (/vedic/doshas/*), Джайміні (/vedic/jaimini/*), сумісність (/vedic/compatibility/*), KP (/vedic/kp/*, включно з куспідами домів), йоги (/vedic/yogas/*), Шадбала, Аштакаварга, раші-дашы (Чара/Стхіра/Шула) і Лал Кітаб, а також звіт Vedic Kundli. Тепер лагна (і куспіди для KP/Шадбали) сидерична, а ayanamsa у відповіді варги більше не дорівнює 0. Для народжень, де тропічний і сидеричний асцендент потрапляють у різні знаки, знак лагни та залежні від нього значення (доми, доші, арудхи, раші-дашы, KP sub-lords, сила домів) зміняться. Це виправлення, а не регресія.

Дати періодів у Вімшоттарі та інших дашах тепер у локальному поясі народження, а не UTC (народження 02:05 більше не показується як попередній день). Точний момент лишається у полях startJd/endJd. Fusion-ендпоінти (/forecast/multi-system, /forecast/yearly-fusion) тепер теж рахують махадашу від сидеричного Місяця (раніше брали тропічний, через що володар дашы міг бути неправильним) і показують дати локально.

Поле пояса приймає лише числовий timezoneOffset (години від UTC). Назва пояса ("timezone": "Asia/Kathmandu") тепер повертає 400 замість тихого розрахунку в UTC.

Що зробити: перерахуйте кешовані ведичні результати, бо знак лагни міг змінитися; для точного моменту періодів даш беріть startJd/endJd; замініть назви поясів на числовий timezoneOffset (напр. 5.75).

2026-07-10 · POST /v1/aspects, окремий ендпоінт для аспектів

Новий ендпоінт для одного лише розрахунку аспектів - без planets / houses / midpoints payload-у /chart. Tier 1: 10 кредитів за виклик.

curl -X POST https://api.astroway.info/v1/aspects \
  -H "X-Api-Key: aw_live_..." \
  -H "Content-Type: application/json" \
  -d '{"date":"1926-06-01","time":"09:30:00","timezoneOffset":-8,"latitude":34.05,"longitude":-118.24}'

Повертає count + aspects[] де кожен аспект має planet1 / planet2 / type (object з name, angle, orb, symbol, isMajor, i18nKey, color) / exactAngle / orb / isApplying.

Per-pair орб-матриця як у astro.com (правило MIN з двох планет). Та сама calcAspects() що використовує /chart - числа ідентичні subtree /chart.aspects.

2026-07-03 · POST /v1/houses, окремий ендпоінт для будинків

Новий ендпоінт для одного лише розрахунку домів - без planets / aspects / midpoints / etc payload-у /chart. Tier 1: 10 кредитів за виклик.

curl -X POST https://api.astroway.info/v1/houses \
  -H "X-Api-Key: aw_live_..." \
  -H "Content-Type: application/json" \
  -d '{"date":"1990-05-15","time":"14:30:00","timezoneOffset":3,"latitude":50.45,"longitude":30.52,"houseSystem":"P"}'

Повертає houses.cusps (12 longitudes) + ascendant + mc + armc + vertex + equatorialAsc + опціональні coAscWK / coAscMunkasey / polarAsc + warning якщо запитана quadrant-система впала на extreme latitude і SwEph підставив Porphyry (|lat|>66.5°).

Підтримка houseSystem: P (Placidus, default) / K (Koch) / R (Regiomontanus) / C (Campanus) / T (Topocentric) / M (Morinus) / W (Whole Sign) / E (Equal) / O (Porphyry) - та ще кілька варіантів через Swiss Ephemeris C-code.

Раніше за окремими cusps потрібно було робити POST /v1/chart (важчий payload). Тепер є legacy-compatible альтернатива для callers які хочуть лише дома без додаткового computed weight.

2026-06-26 · Onboarding wizard: AI endpoint discovery + sandbox first call

POST /v1/me/recommend-endpoints приймає текстовий опис use case, повертає top-5 endpoints з прикладами коду на curl/JS/Python.

curl -X POST https://api.astroway.info/v1/me/recommend-endpoints \
  -H "Authorization: Bearer <jwt>" \
  -H "Content-Type: application/json" \
  -d '{"description":"Dating app with compatibility scores"}'
# {
#   "detected_use_case": "relationship-compatibility",
#   "recommendations": [
#     { "endpoint": "/v1/synastry", "title": "Couple synastry",
#       "why": "Returns aspects between two charts", "credits_per_call": 50,
#       "code_example": { "language": "curl", "snippet": "..." } },
#     ...
#   ]
# }

Powered by LLM gateway. Маршрут use case → endpoints живе як prompt у ai.astroway.info - оновлюється без redeploy API.

Dashboard integration. Step 3 в /dashboard/onboarding wizard тригерить цей endpoint. Same endpoint доступний як standalone /dashboard/discover для existing users.

2026-06-23 · API локалізації контенту: /v1/translate/*

Астро-орієнтований машинний переклад на 20 мов. Чотири ендпоінти:

• POST /v1/translate/astro: один текст (до 3000 символів)
• POST /v1/translate/batch: до 25 рядків зі спільною цільовою мовою
• GET /v1/translate/languages: список підтримуваних мов (безкоштовно)
• GET /v1/translate/glossary/{lang}: вивантаження доменного глосарія (безкоштовно)

Доменний глосарій зберігає спеціальні терміни (Dasha, Nakshatra, асцендент, …) - вони не калічаться буквальним перекладом. Числові поля не торкаються. Джерело за замовчуванням англійська; передайте source_lang для іншого.

Кредити: 15 + ⌈символи/40⌉ за виклик (батч - за сумою символів). Списується з кредитів вашого тарифу. Ліміти: astro ≤3000 симв; batch ≤25 рядків, ≤2000 симв/рядок, ≤20000 разом.

2026-06-19 · POST /v1/moon-phase, фаза Місяця на момент часу

Новий ендпоінт: поточна фаза Місяця для довільної дати/часу/локації. Tier 1: 10 кредитів за виклик.

curl -X POST https://api.astroway.info/v1/moon-phase \
  -H "X-Api-Key: aw_live_..." \
  -H "Content-Type: application/json" \
  -d '{"date":"2024-01-25","time":"12:00:00","latitude":0,"longitude":0,"timezoneOffset":0}'

Повертає phase (0..1), phaseName (New Moon / Waxing Crescent / First Quarter / Waxing Gibbous / Full Moon / Waning Gibbous / Last Quarter / Waning Crescent), majorPhase (new_moon / quarter / full_moon / between), illuminationPercent, elongationDeg, ageDays (синодичний вік 0..29.53), waxing, moonSign, sunSign, moonLongitude, sunLongitude.

Геоцентрична Sun-Moon елонгація за Meeus Ch.48 - алгоритмічно еквівалентно RapidAPI Astrologer /moon-phase/context. Раніше радили POST /v1/render/moon-phase із format: json як обхідний шлях - він повертає той самий розрахунок поряд із SVG; новий /moon-phase віддає чисто розрахунок без SVG-payload (легший, дешевший на network).

2026-06-17 · Виправлено схеми відповідей (/openapi.json) + nullable-поля

Повний аудит схем виявив ~19 ендпоінтів, де опублікована схема 200-відповіді розходилася з фактичним виводом - наприклад, у /chart поле aspects[].type було описане як рядок, а повертається об’єкт; так само координати ACG, поля Human Design (/human-design, /hd/*), Vedic (/vedic-divisional, /vedic/lal-kitab/*), /almuten, /sabian-symbols, /midpoint-trees та ін. Через це MCP-клієнти відхиляли виклики цих інструментів з помилкою -32602 Output validation error, а SDK зі строгою типізацією могли падати на розборі. Усі схеми приведено у відповідність до реального виводу.

Додатково: поля у виведених схемах тепер позначені як nullable. Реальні відповіді повертають null для умовних полів, а строга валідація раніше це відхиляла - тепер null приймається коректно.

Розрахунки не змінювалися - виправлено лише опис схем. Якщо ви генерували типи зі старого /openapi.json, перегенеруйте їх. Користувачі MCP (@astroway/mcp та hosted) отримають виправлення автоматично.

2026-06-15 · Вартість стрімінгу та вебхуків у кредитах

Уточнено тарифікацію стрім- і вебхук-ендпоінтів. /stream/* (10 ендпоінтів) тарифікуються як Tier 1: 10 кредитів за виклик (окремої “дешевшої” ставки за тік немає). CRUD-операції /webhooks/* - теж Tier 1; сама доставка події на ваш URL не тарифікується.

Що зробити: якщо опитуєте стрім-ендпоінт у циклі - рахуйте бюджет як 10 кредитів × частота й використовуйте поля tickSeconds / nextEventAt з відповіді, щоб не опитувати частіше, ніж змінюється стан. Деталі - Кредити та ліміти.

2026-06-13 · API-відповіді у 20 мовах через Accept-Language

Усі ендпоінти, що повертають текстовий контент, тепер реагують на заголовок Accept-Language. Прикладом, Accept-Language: hi для /v1/horoscope/daily поверне гороскоп гінді; Accept-Language: de для /v1/interpret/planet-in-sign - німецьку інтерпретацію.

Підтримувані мови: uk · en · de · pl · es · pt · hi · fr · ko · it · ja · id · tr · nl · cs · ro · vi · ar · el · hu (20).

• Альтернатива: ?lang=xx query-параметр для клієнтів, що не контролюють заголовки
• Дефолт: джерельна мова uk, якщо Accept-Language не вказано або мова поза списком
• Чисельні поля (longitude, latitude, speed, sign-id, house-id) не торкаються - клієнт сам форматує
• Спеціальні терміни (Raj Yoga, Sade Sati, тощо) зберігаються в оригінальній формі через глосарій

Документація: /languages сторінка та OpenAPI specifications для кожного ендпоінту.

Підтримка у SDK (TS / Python / PHP) та MCP-сервері з’явиться у найближчих релізах кожного пакета - див. дорожні мапи.

2026-06-11 · Free-тариф обмежено до Tier 1-3 (важкі ендпоінти → Indie+)

Безкоштовний тариф тепер покриває лише ендпоінти Tier 1-3 (до 50 кредитів). Будь-який ендпоінт Tier 4+ на Free повертає 402 PLAN_UPGRADE_REQUIRED з upgrade_to: 'indie'. Зачеплені: важкі багатоденні скани (transit-calendar, forecast-calendar, eclipses, ingresses, planetary-cycles, solar-acg, phase-return, aspect-timeline тощо), ректифікація (rectification, rectification/trutine), мульти-персон HD (hd/penta, hd/group-overlay, human-design/compatibility), усі PDF-звіти (reports/*) і AI-наративи (reports/ai/*).

AI-інтерпретація лишається безкоштовною: interpret/* та horoscope/yearly доступні на Free, як і раніше.

Що зробити: якщо ваш Free-ключ звертається до Tier 4+ ендпоінта - перейдіть на Indie ($5/міс, 50K кредитів) на astroway.info/pricing або звіртеся з публічною таблицею вартості /credits/ (маркер доступності на Free у кожному рядку).

2026-06-09 · /iching deprecated → namespace /iching/*

Голий POST /v1/iching (legacy випадковий кид гексаграми) позначено deprecated. Уся робота з I Ching живе в namespace /v1/iching/*: throw-coins (із seed), by-question, with-changing-lines, daily, lookup/{n} - на наборі Wilhelm-Baynes. Старий ендпоінт працює до 2027-06-16 (sunset) і повертає Deprecation / Sunset / Link: rel="successor-version".

Що зробити: замість POST /v1/iching використовуйте POST /v1/iching/throw-coins (підтримує seed для відтворюваності) або інший ендпоінт /iching/*.

2026-06-08 · /vedic-divisional deprecated → /vedic/varga/{D1..D60}

Загальний POST /v1/vedic-divisional (де варга передавалася в тілі) позначено deprecated на користь окремих ендпоінтів POST /v1/vedic/varga/{D1..D60} - чистіша OpenAPI/SDK-сигнатура й багатший вивід (назва варги, lagna, ayanamsa). Старий ендпоінт продовжує повноцінно працювати до 2027-06-15 (sunset, у межах гарантії стабільності /v1 ≥12 міс) і повертає заголовки Deprecation: true, Sunset: Tue, 15 Jun 2027 00:00:00 GMT, Link: …; rel="successor-version". Після цієї дати його буде видалено.

Що зробити: перенесіть виклики POST /v1/vedic-divisional із тілом { "varga": "D9", … } на POST /v1/vedic/varga/D9 (варга у шляху, решта тіла без змін).

2026-06-06 · Публічні read-ендпоінти без ключа (легкі віджети)

Набір GET /v1/public/* ендпоінтів, які працюють без авторизації (IP-rate-limited 30/год, кожна відповідь несе _footer watermark). Зручно для copy-paste cURL у документації та легких інтеграцій без реєстрації:

• GET /v1/public/horoscope/daily?sign=aries&date=YYYY-MM-DD: денний гороскоп за знаком
• GET /v1/public/horoscope/weekly?sign=…: тижневий
• GET /v1/public/horoscope/monthly?sign=…: місячний
• GET /v1/public/tarot/daily?date=…: карта дня (RWS, детермінована на добу)
• GET /v1/public/moon-phase?date=…: фаза Місяця (детермінований розрахунок)
• GET /v1/public/planet-of-day?date=…: планета-управитель дня тижня

Усі 12 знаків Зодіаку; date необов’язковий (типово сьогодні), невалідний знак/дата → 400. Гороскопи AI-генеровані й кешуються per (знак, період, мова); тиждень/місяць рахуються від понеділка/першого числа. Решта - детермінований розрахунок. Мова через Accept-Language.

2026-06-05 · Self-service webhooks: /v1/me/webhooks CRUD + HMAC delivery worker

Subscriptions endpoint family для outgoing webhooks. Раніше webhook-таблиця (migration 017) існувала лише для admin-side - тепер відкриваємо CRUD юзерам через dashboard /webhooks сторінку.

# Create
curl -X POST https://api.astroway.info/v1/me/webhooks \
  -H "Authorization: Bearer <jwt>" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://myapp.com/astroway-webhook",
    "events": ["credits.threshold_crossed", "key.revoked", "request.failed"]
  }'

# List
curl -H "Authorization: Bearer <jwt>" https://api.astroway.info/v1/me/webhooks

# Test ping (send sample event)
curl -X POST https://api.astroway.info/v1/me/webhooks/<id>/test \
  -H "Authorization: Bearer <jwt>"

7 типів подій: credits.threshold_crossed, key.revoked, key.created, request.failed (5xx), billing.invoice_paid, billing.invoice_failed, plan.changed.

HMAC підпис. Кожна доставка несе X-AstroWay-Signature: t=<unix>,v1=<hex> де v1 - це HMAC-SHA256(secret, "t=<unix>.<body>"). Secret видається раз під час create і його можна ротувати (POST /me/webhooks/<id>/rotate-secret).

Delivery worker. Background process (новий astroway-webhook-worker в PM2) тягне queue, виставляє exponential backoff на 5xx відповіді клієнта: 1m / 5m / 30m / 2h / 12h. Після 5 fail-ів - webhook auto-suspend з email алертом.

Dashboard page. /dashboard/webhooks з list + create modal + test button + delivery history. Sidebar nav entry в Account section.

2026-06-03 · GET /v1/reports/history: список останніх згенерованих звітів

Новий ендпоінт повертає ваші нещодавно згенеровані PDF-звіти - тип, розмір, кількість сторінок, мову, час створення й закінчення та url. Зручно, щоб повторно отримати посилання на звіт у межах його 24-годинного терміну дії або показати останні експорти в дашборді. Виклик безкоштовний. Параметр ?limit= (1–50, типово 10).

2026-06-02 · Cache MISS/HIT instrumentation: X-Cache response header

Server logue cache outcome для кожного запиту (X-Cache: MISS | HIT | BYPASS). Це робить можливим cache hit % колонку в /dashboard/usage (зараз показує –).

curl -I -X POST https://api.astroway.info/v1/chart \
  -H "X-Api-Key: aw_live_..." \
  -H "Content-Type: application/json" \
  -d '{...}' | grep -i x-cache
# X-Cache: MISS

Tracking. api_request_log.cache_status column (migration 030, enum). GET /v1/me/usage/endpoints починає повертати реальне cache_hit_pct замість null.

Pricing impact. Кешовані запити продовжують deduct credits на rendered tier - але показ показника в dashboard допомагає оптимізувати інтеграцію (на cache HIT треба, наприклад, не пересилати zustand-style chart payload).

2026-06-01 · GET /v1/version + Swagger/OpenAPI aliases + /v1/v1/* typo redirect

Дрібні зручності для SDK і поодиноких інтегрантів - серії “чому 404 на типовий запит” більше не має бути.

Новий ендпоінт GET /v1/version: безкоштовний, без auth. Повертає поточну версію API + commit + uptime:

curl https://api.astroway.info/v1/version
# {
#   "version": "2.71.0",
#   "build_commit": "abc1234",
#   "started_at": "2026-06-02T08:00:00Z",
#   "uptime_seconds": 12345,
#   "docs_url": "https://api.astroway.info/docs/api/"
# }

SDK можуть викликати на старті для діагностики “чому раптом інша поведінка” - build_commit точно ідентифікує деплой.

OpenAPI-аліаси (301): щоб Postman / Insomnia / openapi-generator знайшли спеку з першої спроби:

/v1/v1/<endpoint> → /v1/<endpoint> (308): фіксить типовий SDK-баг коли baseUrl уже містить /v1 і клієнт додає /v1/X зверху. Метод і body зберігаються, ніщо не ламається мовчки.

/api/health → /v1/health (301), інші /api/<endpoint> → JSON 404 з кодом WRONG_PREFIX: для розробників з wp-json muscle memory. Раніше це було generic-404 від nginx, тепер відповідь дає чітку підказку про правильний префікс.

Документація: нова сторінка URL-конвенції та безкоштовні ендпоінти - повний перелік безкоштовних системних ендпоінтів (/health, /health/deep, /version, /openapi.json, /docs, /reference/*, /i18n/*), безкоштовних обліково-залежних (/auth/*, /me, /keys, /admin/*, /embed/*, /books/*, /messages, /dev-assistant), та платних tier-розкладу.

2026-05-30 · Embed-віджети: опційний параметр ?disclaimer=1

Публічні embed-віджети (GET /v1/embed/*) тепер приймають опційний disclaimer=1 - додає у футер коротку оговорку про розважально-ознайомлювальний характер контенту (не медична, психологічна, фінансова чи юридична консультація). Вимкнено за замовчуванням - без параметра футер не змінюється. Увімкніть, якщо ваш комплаєнс вимагає видимої оговорки на стороні відображення.

<iframe src="https://api.astroway.info/v1/embed/wheel?date=1990-05-15&theme=dark&disclaimer=1"
        width="460" height="560" style="border:0"></iframe>

2026-05-29 · Чотири нові embed-віджети (без ключа, для iframe)

Розширено набір публічних HTML-віджетів GET /v1/embed/* - тепер їх 14. Нові не потребують API-ключа, віддають готовий iframe-фрагмент, обмежені per-IP (30 запитів/год).

• GET /v1/embed/transit?date=: позиції транзитних планет (знак + градус, ретроградність) на дату.
• GET /v1/embed/numerology?name=&date=&system=: Число життєвого шляху / вираження / душі / особистості (system: pythagorean або chaldean).
• GET /v1/embed/panchang?date=&lat=&lng=&tz=: тітхі / накшатра / йоґа / карана / вара + схід/захід Сонця + Раху-каал.
• GET /v1/embed/synastry?date_a=&time_a=&lat_a=&lng_a=&tz_a=&date_b=…: оцінка сумісності + ключові міжкартові аспекти для двох субʼєктів.

<iframe src="https://api.astroway.info/v1/embed/transit?date=2026-05-29&theme=dark"
        width="460" height="420" style="border:0"></iframe>

Усі віджети приймають theme (dark/light/console) та lang. Кешуються public, max-age=300.

2026-05-28 · Виправлено документацію кодів помилок

Довідник помилок тепер відповідає реальним відповідям API. Коди - UPPER_SNAKE_CASE (наприклад INVALID_INPUT, INVALID_API_KEY, CREDITS_EXHAUSTED), конверт - { ok: false, error: { code, message, details? } }, а помилки валідації (INVALID_INPUT, HTTP 400) містять details: [{ path, message }]. Якщо у вас switch (error.code) по раніше задокументованих lowercase-назвах - оновіть на реальні коди. Самі відповіді API не змінювались.

2026-05-26 · Новий ендпоінт POST /v1/reports/generate, V2 unified dispatcher

Замість 12 type-specific роутів (/reports/natal, /reports/synastry, …) - один ендпоінт із report_type enum, який диспатчить на відповідний рендерер. SDK-консументи отримують один метод замість дванадцяти; MCP-каталог - один інструмент замість дванадцяти.

curl -X POST https://api.astroway.info/v1/reports/generate \
  -H "X-Api-Key: aw_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "report_type": "natal",
    "chart": {"date":"1990-05-15","time":"14:30:00","timezoneOffset":3,"latitude":50.45,"longitude":30.52,"name":"Test"},
    "language": "uk",
    "whitelabel": { "themeColor": "#ff5500", "reportName": "My Cosmic Map" }
  }'

12 supported report_type values: natal, transit-yearly, synastry, business, career, love, money, child, lal-kitab, human-design, tarot, vedic-kundli.

Per-type required fields validated в handler: natal/business/career/etc - chart; synastry - chart1 + chart2; tarot - seed (optional). Missing required fields → 400 with MISSING_CHART / MISSING_CHARTS error code.

Зворотна сумісність. Всі 12 type-specific ендпоінтів залишаються - /v1/reports/generate додано як additive surface, не replacement. Можна вибрати або: direct (client.reports.natal({...})) або generic (client.reports.generate({ report_type: 'natal', ... })).

Pricing. Forwarded per-renderer (natal → TIER_7, transit-yearly → TIER_8, tarot → TIER_4, тощо). Сам dispatcher не додає окремої вартості.

OpenAPI 3.1. GenerateReport - окремий компонент в /v1/openapi.json. SDK regen у наступному релізі додасть метод client.reports.generate().

2026-05-25 · Jaimini-розширення (+5 ендпоінтів)

П’ять нових ендпоінтів для глибокого аналізу за школою Jaimini - раніше були відкладені, тепер у проді.

• POST /vedic/yogas/jaimini/karaka-yoga: скан усіх 8 чара-карак (Atmakaraka..Darakaraka) з оцінкою сили розміщення в кендрі / тріні / душтхані та підказкою маніфестації для кожної.
• POST /vedic/yogas/jaimini/karakamsa: повна 12-будинкова проекція з знаку Атмакараки в D9. Кожен будинок несе канонічні значення (іштадевата, мокша, духовний шлях) за коментарем Sanjay Rath.
• POST /vedic/yogas/jaimini/shubha-graha: функціональна природа всіх 7 видимих грах (yogakaraka / functional-benefic / neutral / functional-malefic / maraka) залежно від володіння будинками від Лагни. Кендрадхіпаті- + мараку-правила за BPHS A.34.
• POST /vedic/jaimini/atmakaraka-rotation: таймлайн зміни Атмакараки протягом життя через символічну прогресію 1°/рік. Повертає вік-події з ім’ям планети до/після переходу.
• POST /vedic/jaimini/argala-analysis: повний скан Argala (2/4/11 первинна, 5 вторинна, 8 спеціальна) + Virodhargala (12/10/3 первинна, 9 вторинна, 6 спеціальна) для всіх 12 будинків з net-influence та dominant-over.

Усі п’ять - окремі вартісні групи (Tier 2: 20 кредитів, окрім atmakaraka-rotation Tier 3: 50 кредитів через time-series compute). Доступні на Vedic Pack add-on.

2026-05-19 · whitelabel приймає inline-об’єкт брендингу (15 полів)

Поле whitelabel у схемах усіх 12 ендпоінтів /v1/reports/* (natal, transit-yearly, synastry, business, career, love, money, child, lal-kitab, human-design, tarot, vedic-kundli) тепер приймає не лише boolean, а й об’єкт із брендингом - без необхідності прив’язки до WordPress-користувача через whitelabel_configs таблицю.

curl -X POST https://api.astroway.info/v1/reports/natal \
  -H "X-Api-Key: aw_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "chart": {"date":"1990-05-15","time":"14:30:00","timezoneOffset":3,"latitude":50.45,"longitude":30.52,"name":"Test"},
    "whitelabel": {
      "companyName": "Acme Astrology",
      "companyUrl": "https://acme-astro.example.com",
      "logoUrl": "https://cdn.example.com/logo.png",
      "themeColor": "#ff5500",
      "reportName": "My Personal Cosmic Map",
      "footerText": "© 2026 Acme Astrology",
      "fontPairing": "serif-sans"
    }
  }'

PDF/HTML рендериться з вашим лого в шапці, заміненою назвою звіту, відповідними кольорами теми та блоком контактів у футері.

15 полів об’єкта (усі опціональні): companyName, companyUrl, companyEmail, companyMobile, companyBio, logoUrl (https + .png/.jpg/.svg/.webp), frontImage, textPrimaryColor/textSecondaryColor/backgroundColor/themeColor/headingColor (всі #RGB або #RRGGBB), footerText, fontPairing (serif-sans/sans-serif/serif-only/sans-only/system), reportName.

Зворотна сумісність. whitelabel: true (читає DB-конфіг для прив’язаного WP-користувача) та whitelabel: false/відсутнє - поведінка незмінна. Поле тепер boolean | BrandingObject.

Resolution priority. Inline-об’єкт зливається поверх DB-конфігу (якщо ключ прив’язано до WP-користувача) або поверх дефолтів (для SDK-користувачів без WP). themeColor стає primaryColor після applyBrandingPreferences, fontPairing мапиться на CSS font-family.

OpenAPI 3.1 spec. BrandingObject - окремий компонент у /v1/openapi.json. SDK-кодген отримає типізований BrandingObject під час наступної регенерації (TS / Python / PHP).

2026-05-16 · Hosted MCP endpoint live at mcp.astroway.info/mcp

@astroway/mcp тепер доступний у двох транспортних режимах. Stdio (npm-пакет) залишається без змін; додано hosted Streamable HTTP endpoint для zero-install інтеграції в Claude Web (claude.ai у браузері), Claude Desktop, Cursor, Cline та інші MCP-сумісні клієнти.

Установка в один клік для Cursor - кнопка cursor://anysphere.cursor-deeplink/mcp/install?... на сторінці /examples/mcp/. Claude Desktop - через + → Add Connector → Custom (без редагування JSON).

// JSON-варіант для Cline / Continue / Windsurf
{
  "mcpServers": {
    "astroway-hosted": {
      "url": "https://mcp.astroway.info/mcp",
      "headers": {
        "Authorization": "Bearer aw_live_..."
      }
    }
  }
}

Той самий каталог 630 інструментів + 12 промптів + 14 ресурсів, та сама aw_test_* / aw_live_* авторизація (у hosted режимі через Authorization: Bearer … header замість env var), той самий credit pool. Multi-tenant by design - кожен запит несе свій ключ, кредити списуються з акаунта власника ключа. Канал у X-Astroway-Channel - mcp-http (hosted) vs mcp (stdio) для adoption tracking.

Чому два режими. Stdio (npx @astroway/mcp) залишається для Cursor power users / privacy-conscious інтеграторів - ключ ніколи не залишає машину, без мережевих хопів. Hosted закриває сегмент Claude Web (який підтримує тільки remote MCP) та zero-install scenarios. Той самий шаблон, що у Stripe / Resend / GitHub MCP.

Health endpoint: публічно reachable без авторизації:

curl https://mcp.astroway.info/health
# {"status":"ok","version":"…","uptime_sec":…,"mcp_protocol_version":"2024-11-05"}

Повна документація обох режимів - /examples/mcp/.

2026-05-15 · Новий ендпоінт GET /v1/auth/keys/me

Інтроспекція API-ключа. Передаєш X-Api-Key - отримуєш повний стан: план, кредити, статус, прив’язаний домен, час створення, джерело реєстрації. Корисно для SDK-консумерів (TS / Python / PHP / MCP) - “що в мене за ключ зараз” без read’у дашборду. Аналог Stripe /v1/account або GitHub /user.

curl -H "X-Api-Key: aw_live_..." https://api.astroway.info/v1/auth/keys/me
# →
# {
#   "key_prefix": "aw_live_4ab...",     # перші 11 символів, повний ключ ніколи не повертаємо
#   "plan": "free",
#   "credits_remaining": 9830,
#   "credits_total_this_period": 10000,
#   "period_end": "2026-06-01T00:00:00.000Z",  # календарний кінець місяця
#   "status": "active",                  # active | suspended | revoked
#   "domain": null,                      # домен, до якого ключ прив'язано (wp-plugin keys)
#   "domain_bound_at": null,
#   "created_at": "2026-04-24T22:03:59.000Z",
#   "referrer_source": "direct"          # direct | wp_plugin | mcp | sdk | dashboard | other
# }

Без auth: 401 MISSING_API_KEY. Невалідний ключ: 401 INVALID_API_KEY.

OpenAPI 3.1 spec. /v1/openapi.json тепер декларує /v1/auth/keys/me. SDK-кодген пропише client.auth.keys.me() під час наступної регенерації.

Зворотна сумісність. Старий GET /v1/keys/usage (повертав тільки credits_today + ratelimit) продовжує працювати - це окремий ендпоінт для серверних cron-перевірок. /auth/keys/me повертає повний state plus domain binding для wp-plugin сценаріїв.

2026-05-14 · Локалізація /horoscope/* та /interpret/* (20 мов)

POST /v1/horoscope/{daily,weekly,monthly,yearly,compatibility} та POST /v1/interpret/{natal,synastry,transits,element,placement} - 10 ендпоінтів, що повертають текст інтерпретації - тепер віддають відповідь у мові клієнта.

Як підключити:

curl -X POST https://api.astroway.info/v1/horoscope/daily \
  -H "X-Api-Key: aw_live_..." \
  -H "Accept-Language: hi" \
  -H "Content-Type: application/json" \
  -d '{"sign": "leo"}'
# → відповідь у हिन्दी

Resolve-priority (server-side):

1. body.language="de" - явний per-call параметр (вищий пріоритет)
2. Accept-Language: de, en;q=0.7 - RFC 7231 q-weighted; перший код, що збігається з активною мовою, виграє
3. ?lang=de - query-параметр для клієнтів, що не контролюють заголовки
4. Fallback → uk (джерельна мова)

Підтримувані мови (20): uk, en, de, pl, es, pt, fr, it, nl, cs, ro, hu, el, tr, ar, hi, ja, ko, vi, id. Невідомі коди тихо падають у uk без помилок.

OpenAPI 3.1 spec. /v1/openapi.json тепер декларує Accept-Language (header) та lang (query) як параметри з enum 21 кодів на цих 10 ендпоінтах. SDK-кодген (openapi-typescript, openapi-generator-cli) автоматично пропише типізовані виклики .lang('hi') під час наступної регенерації.

Що перекладається: тільки текстові поля інтерпретації (horoscope, interpretation, disclaimer тощо). Числові поля (longitude, latitude, score, ID-знаків, ID-домів) залишаються канонічними - клієнт форматує локально. Сегментний стандарт (Vedika, DivineAPI, AstrologyAPI.com).

Скоуп: наразі локалізуються 10 ендпоінтів інтерпретаційної групи. Калькуляційні ендпоінти (/chart, /synastry, /transits, /vedic/*, /human-design/*, /tarot/*, /numerology/*, ~690 інших) повертають числа й канонічні ідентифікатори (name: "Aries", glyph: "♈") незмінно - клієнт локалізує їх через свої lookup-таблиці. Це сегментний стандарт.

Backwards compatible. Існуючий код без Accept-Language / ?lang= / body.language отримує uk за замовчуванням, як і раніше.

SDK-підтримка (@astroway/sdk, astroway, astroway/sdk, @astroway/mcp) додає lang опцію в конструкторі - окремі релізи приходять найближчими тижнями через cron-applier на staging-репозиторіях.

2026-05-09 · Three SDKs launched: TypeScript, Python, PHP

Три офіційних SDK живуть на public registries - обертки навколо тих самих 700+ ендпоінтів API. Один OpenAPI 3.1 spec → три language-idiomatic клієнти.

Що це для інтегратора:

• Type-safe alternative до raw HTTP. Path autocomplete + типи запитів і відповідей в IDE. Helper-методи aw.post('/chart', body=...) (Python/PHP) або aw.client.POST('/chart', { body }) (TS) - замість ручного fetch / requests / Guzzle.
• Identical surface across languages. Constructor Astroway({apiKey, baseUrl, authScheme, timeout, retry}) працює однаково в TS / Python / PHP. Якщо проект мульти-мовний - менше cognitive overhead.
• Built-in retry на 408/409/429/5xx з exponential backoff + full jitter. Honors Retry-After header. Default 2 retries, configurable через retry={maxRetries: 0}.
• Stainless-template ієрархія помилок: той самий шаблон що в SDK Stripe / OpenAI / Cloudflare. Ловіть RateLimitError (з retryAfterSeconds), AuthenticationError (rotate key), BadRequestError (validation), ApiError (generic) - у такому порядку.
• Two auth schemes. За замовчуванням X-Api-Key: aw_live_... (як у curl/Postman). Або Authorization: Bearer aw_live_... (як у Stripe/OpenAI/Anthropic SDK) - auth_scheme="bearer" в конструкторі.
• Identification headers, no telemetry. Кожен запит несе User-Agent: astroway-sdk-<lang>/<version> + X-Astroway-Channel: sdk-<lang>. Жодного phone-home, жодного opt-in/opt-out перемикача.
• OIDC + SLSA L3 provenance (TS + Python). Sigstore-attested record що пакет збудований з конкретного коміту в публічному репо. Без long-lived tokens у CI.
• MIT, full source open на github.com/astroway/{astroway-typescript,astroway-python,astroway-php}.

Quick start:

// TypeScript / Node 20+
import { Astroway } from '@astroway/sdk';
const aw = new Astroway({ apiKey: process.env.ASTROWAY_API_KEY! });
const { data } = await aw.client.POST('/chart', { body: { date: '1990-07-14', /* ... */ } });

# Python 3.9+
from astroway import Astroway
aw = Astroway(api_key=os.environ['ASTROWAY_API_KEY'])
chart = aw.post('/chart', body={'date': '1990-07-14', ...})

// PHP 8.1+
use Astroway\Astroway;
$aw = new Astroway(['apiKey' => getenv('ASTROWAY_API_KEY')]);
$chart = $aw->post('/chart', body: ['date' => '1990-07-14', /* ... */]);

Async варіант для Python - AsyncAstroway з identical surface через async/await. У PHP - sync only (PHP не має unified async story). У TS - native promises на base of openapi-fetch.

Це alpha - public API може зміщуватися до 0.1.0 proper на основі feedback інтеграторів. Закріпіть точну версію (@astroway/sdk@0.1.0-alpha.1) під час alpha-вікна - або latest alpha на момент install.

@astroway/mcp - MCP-сервер для Claude / Cursor / GPT - продовжує жити поряд як окремий продукт.

2026-05-07 · MCP server refresh

@astroway/mcp оновився - auto-генерує tool catalog з поточного /openapi.json без ручного редагування. Все, що з’явилося в API за останні тижні (compat suite, reports endpoints), одразу видно Claude / Cursor / GPT.

Для інтегратора:

• Tool catalog відображає живий стан API
• Path-template ендпоінти (/v1/.../id) пропускаються поки що, щоб не плутати дискріб-парсер
• Cost annotations в description tool: Claude бачить вартість виклику до execution
• OIDC trusted publishing + SLSA L3 provenance: пакет attested до конкретного коміту в public repo astroway/astroway-mcp

Установка:

npm install -g @astroway/mcp

Або через Claude Desktop / Cursor MCP config:

{
  "mcpServers": {
    "astroway": {
      "command": "npx",
      "args": ["-y", "@astroway/mcp"]
    }
  }
}

Source: public astroway/astroway-mcp (MIT).

2026-04-11 · Cross-system compatibility (+10 ендпоінтів)

Нова група /v1/compat/* - composite compatibility score across western, vedic, chinese, numerology, tarot, human design. 6 систем дають unified метрику для UX-індикаторів у multi-traditional астрологічних застосунках.

Кожен ендпоінт повертає JSON з полем disclaimer - це AstroWay scoring methodology, не клінічне або юридичне ствердження. Tier 4 (100 кредитів) per call - heavy cross-system compute.

Manifest на /openapi.json оновлено - SDK / MCP підхоплять автоматично.

2026-03-28 · Reports + Webhooks (+17 ендпоінтів)

Дві нові групи в production.

/v1/reports/* (12 ендпоінтів) - генерація HTML / PDF репортів через Puppeteer. Render на стороні api-calc, signed download URL (TTL 24h).

/v1/webhooks/* (5 ендпоінтів) - subscription management, event delivery, HMAC signing. Підписка на події credits.low, key.created, usage.threshold, error.spike.

curl -X POST https://api.astroway.info/v1/webhooks \
  -H "Authorization: Bearer aw_live_..." \
  -d '{"url": "https://...", "events": ["credits.low"], "secret": "wh_secret_..."}'

Кожен delivery несе X-Astroway-Signature: sha256=<hmac> - verify через secret. Retry policy: exponential backoff на 5xx, до 5 спроб за 24 години.

2026-03-14 · Reference endpoints: public, без ключа, без кредитів

14 ендпоінтів /v1/reference/* (signs, planets, houses, aspects, elements, modalities, polarities, dignities, decans, nakshatras, lots, asteroids, zodiac-systems, glyphs) тепер працюють без X-Api-Key і коштують 0 кредитів. Це канонічні lookup-таблиці - гейтити їх через білінг було проектним недоглядом.

Що це для інтегратора:

• Виклик без ключа: зовнішні MCP-агенти / SDK / прев’ю-сторінки можуть тягнути reference дані без авторизації. IP rate-limit як на /public (30 запитів / годину) залишається.
• Cost manifest оновлено: 14 шляхів пере́йшли з TIER_HALF (5 кредитів) на 0. Якщо ваш бюджет-планер astroway_cost_estimate посилається на ці шляхи - нові виклики не торкають квоту.
• Існуючі клієнти з ключем працюють без змін. X-Api-Key ігнорується для /reference/* (не прискіплюємось до зайвого header’а).

Backward-compatible: 200-відповіді й JSON-схема не змінюються, лише вимога авторизації знята.

2026-03-07 · Founders’ Lifetime Deal: $299 → тариф Indie на все життя

Запускаємо Founders’ Lifetime Deal - обмежений запуск. Перші 100 клієнтів платять $299 одноразово і отримують тариф Indie (50 000 кредитів/міс) назавжди, без рекурентних списань, із зафіксованою ціною.

Що це для інтеграторів:

• Стандартний Indie = $5/міс. Founders’ = одноразово $299 → точка окупності на 5-му році, далі безмежний ROI. Якщо ваш проєкт хоча б 5 років в астрології / нумерології / Таро - Founders’ окупається.
• Webhook payload на checkout SKU astroway-api-indie-lifetime: рядок api_keys отримує plan='indie', credits_limit=50000, is_lifetime=1, expires_at=NULL. Жодних щомісячних списань, жодних renewal-вебхуків.
• Схема БД: додано колонки is_lifetime TINYINT(1) в api_keys і shared_user_quotas. TS-тип ApiKeyInfo розширено. Існуючі ключі = is_lifetime=0 (без зміни поведінки).
• WP REST endpoint GET /wp-json/astroway/v1/founders-count повертає {sold, total: 100, remaining, available} - використовується site/components/founders/FoundersCounter.astro для лічильника в реальному часі на сторінці /founders/.
• Авто-деактивація на 100/100: _stock_status товару WC автоматично переходить в outofstock через хук WC woocommerce_order_status_completed. Після цього посилання checkout перенаправляє на /pricing/#indie (стандартний Indie $5/міс).

Live pages: /founders/ (uk) + /en/founders/ (en). Sidebar entry “Founders’ Lifetime Deal” з 🚀 100 only badge.

WP product: astroway-api-indie-lifetime, ID 30618, $299 (13225 UAH), stock=100. Checkout: astroway.info/checkout/?add-to-cart=30618.

2026-03-05 · GDPR / EU residency landing page + Pro card EU badge

Запускаємо /eu/ - окрему сторінку для EU-розробників, чий продукт чутливий до GDPR. Інтегратору важливо знати:

• Pro $59 = EU-резидентність за замовчуванням (Hetzner Nuremberg, потік даних тільки в межах ЄС, анонімізована аналітика - Plausible cookie-free у роадмапі).
• Стандартний DPA доступний не тільки на Enterprise: підписується через email на стандартному тарифі Pro за 5 робочих днів.
• DELETE /v1/me/account: ендпоінт для GDPR right-to-erasure (миттєво видаляє ваш wp_user_id з усіх таблиць).
• Картка Pro на /pricing/ тепер має значок 🇪🇺 GDPR-ready: клік веде на /eu/ з повним FAQ.
• DivineAPI / AstrologyAPI / Prokerala: хостинг US/Індія, DPA тільки на Enterprise. Якщо відповідність GDPR критична - Pro $59 найдешевший шлях.

Сторінки: /eu/ (uk) + /en/eu/ (en). Запис у боковій навігації “GDPR / EU residency” зі значком 🇪🇺.

2026-03-03 · Річна передоплата −25% + перенесення кредитів + публічні фічі Pro

Дві зміни, що впливають на код інтеграторів:

• Річна знижка 17% → 25% (3 місяці безкоштовно замість 2). Нові USD-ціни на рік: Indie $45, Starter $171, Pro $531, Business $1791, HD/Esoteric Pack $81, Vedic Pack $171, Reports Pack $891. Існуючі річні підписники не зачіпаються - нова ціна застосовується лише до майбутніх поновлень підписки. Якщо ви парсили USD-ціни через /wp-json/astroway/v1/api-prices - оновлені значення тепер віддаються автоматично.
• Перенесення кредитів для річних підписників: невикористані кредити переходять на наступний місячний цикл, обмежені 1× місячним лімітом тарифу. Активується автоматично при оформленні річного плану. Видно через нові заголовки відповіді:
  • X-Credits-Limit: <int>: ефективний місячний ліміт (включає перенесення)
  • X-Credits-Remaining: <int>: як було, але з урахуванням перенесення
  • X-Credits-Rollover: <int>: поточний баланс перенесених кредитів (тільки для річних)
• Тариф Pro ($59) тепер відкрито рекламує: streaming-ендпоінти (в реальному часі), GDPR-сумісний ЄС-білінг, розширений MCP (multi-agent / debate / RAG), webhooks (10 типів). Це функції, що вже були в Pro - раніше були сховані в docs.

Схема БД: додано колонки credit_rollover_enabled TINYINT(1) + credits_rolled_over INT UNSIGNED в api_keys і shared_user_quotas. На початку - обидві = 0 для всіх існуючих ключів.

2026-03-01 · Прозора таблиця вартості кредитів за ендпоінт

Запускаємо публічну сторінку /credits/ з повною розбивкою кредитів по всіх 700+ ендпоінтах. Жоден конкурент (DivineAPI, AstrologyAPI, Prokerala) такої таблиці не публікує - вони беруть фіксований 1 кредит/виклик і приховують внутрішнє маршрутизацію.

Для інтегратора це дає три речі:

• Прозора одиниця економіки: точна вартість $/виклик для кожного ендпоінта (місячні бюджети /pricing/ × вартість тарифу = реальна вартість за виклик).
• Авто-синхронізація з кодом: таблиця генерується під час білду з endpoint-costs.ts. Якщо ми додаємо новий ендпоінт або міняємо тариф - сторінка оновлюється автоматично на наступному деплої.
• Маркер Free-тарифу: колонка показує які ендпоінти потребують Indie+ (значок 🔒, 28 ендпоінтів зараз).

Доступно: /credits/ (uk) і /en/credits/ (en). Перехресні посилання з /rate-limits-credits/ і запис у боковій навігації Starlight (значок “Нове”).

2026-02-27 · Vedic-карти, cosmogram, eclipse-path, star-map (+6 ендпоінтів)

Закриває категорію Visualization на 14/14 ендпоінтів за роадмапом:

• POST /v1/render/wheel-vedic-north: North Indian (diamond) layout. Houses fixed, signs rotate за лагною.
• POST /v1/render/wheel-vedic-south: South Indian (4×4 grid). Signs fixed (Pisces top-left), houses плавають.
• POST /v1/render/wheel-vedic-east: East Indian (Bengali). Квадрат із діагоналями + внутрішнім повернутим квадратом.
• POST /v1/render/cosmogram: Hamburg School / Cosmobiology 90°-дайл (Ebertin 1940 + Witte 1928).
• POST /v1/render/eclipse-path: equirectangular world map з caller-supplied lat/lon-треком; рендерить центральну лінію + смугу заданої ширини.
• POST /v1/render/star-map: stereographic projection списку точок (RA/Dec) із magnitude-масштабуванням.

Усі рендери - pure SVG, без headless-Chrome.

2026-02-25 · Bi-/tri-wheel + composite + biorhythm (+4 ендпоінти)

Чотири нові ендпоінти-візуалізатори, що розширюють SVG-механіку:

• POST /v1/render/bi-wheel: два концентричні кола: внутрішнє натальне + зовнішнє кільце з транзитними (або прогресивними) планетами.
• POST /v1/render/tri-wheel: три кола: natal + progressed + transit.
• POST /v1/render/composite: рендер композитної карти з двох натальних вхідних даних (midpoint composite).
• POST /v1/render/biorhythm: синусоїдальний графік трьох циклів: фізичний (23 дні), емоційний (28), інтелектуальний (33).

Обчислення тут самі, лише рендер; для bi-wheel всі планети двох карт обчислюються паралельно (Promise.all).

2026-02-24 · Візуалізація: SVG-рендеринг (+4 ендпоінти)

Чотири нові ендпоінти повертають SVG-рендери натальних карт і пов’язаних візуалів. Pure server-side - без Puppeteer/headless-Chrome, тому затримка ~10 ms замість 1-2 с і безкоштовно для free-плану.

• POST /v1/render/wheel-western: західне колесо (signs ring + houses ring + planets + aspect lines).
• POST /v1/render/aspect-grid: трикутна матриця аспектів зі знаком + орбом у клітинках.
• POST /v1/render/moon-phase: диск Місяця з освітленням; повертає SVG плюс illuminationFraction, phase, waxing.
• POST /v1/render/timeline: Gantt-стиль для подій-транзитів за період (caller передає масив events).

Опції: size, theme (light / dark / console), format (json повертає { svg, byteLength }, svg віддає image/svg+xml напряму). Базовий tier - 2 кредити за виклик.

2026-02-23 · Типізовані схеми у /v1/openapi.json (612 ендпоінтів, 98%)

/v1/openapi.json тепер повноцінна машинно-читана специфікація і для request bodies, і для response data. Типізовано 612 з 624 POST-ендпоінтів через три послідовні етапи, що приземлились разом:

• Request bodies: 386 ендпоінтів типізовано через components.schemas (128 reusable-компонентів). Серед них 5 спільних (ChartInput, TwoChart, MultiChart, NatalTarget, NatalWrapper) і 123 локальних (DashaInput, MuhuratWindow, ChartWithTnp, WheelWestern тощо). Композиція через allOf для inheritance (DashaInput extends ChartInput).
• Response data: 612 ендпоінтів типізовано через inferrer, що ходить ep.response-прикладами в маніфесті: {type: 'object', properties: {...}} замість плоского {type: 'object'}. Натальна карта тепер декларує data.planets[], data.houses.{ascendant, mc, cusps}, data.aspects[] зі справжніми типами полів.
• Залишок 12 ендпоінтів: dasha pratyantar/sookshma з нерозбірливими shorthand-прикладами в маніфесті - залишаються {type: object}. Backward-compatible, додаємо їх у наступних релізах.

Що це для інтегратора:

• Перегенеруйте OpenAPI-клієнт: openapi-typescript, openapi-fetch, swagger-codegen створять інтерфейси з типизованими полями замість Record<string, unknown>. Code-completion на request bodies + response data працює нативно.
• Postman-колекція на /postman/astroway-api.json оновилась з тих самих типів - імпортуйте, отримайте автозаповнення для всіх типизованих ендпоінтів.

Backward-compatible: попередня форма {"type": "object"} була permissive - всі існуючі клієнти продовжують працювати без змін.

2026-02-21 · Перерахунок цін: Reports об’єднано, Business +500K, Free посилено

Три зміни цін, що впливають на інтеграторів:

• Reports уніфіковано на 5 000 кредитів: /v1/reports/transit-yearly, /v1/reports/vedic-kundli, /v1/reports/lal-kitab зменшено з 10 000 кр до 5 000 кр за виклик (вдвічі дешевше). Усі PDF-репорти тепер коштують однаково - простіша математика для пакетного бюджету.
• План Business +500K кредитів/міс: тариф Business тепер дає 3 500 000 кредитів на місяць (було 3 000 000) за ту саму ціну $199. Існуючі підписники отримають збільшений ліміт автоматично з наступного циклу білінгу.
• План Free: /v1/reports/* потребує платного тарифу: 12 PDF-ендпоінтів (reports/natal, synastry, child, business, career, love, money, transit-yearly, vedic-kundli, lal-kitab, human-design, tarot) тепер повертають 402 PLAN_UPGRADE_REQUIRED для Free-ключів. Решта функціональності - карти, синастрія, прогнози, гороскоп - залишається доступною на Free.

Якщо ваш Free-ключ викликав один з цих ендпоінтів - оновіться до Indie ($5/міс) або вище, або переключіться на JSON-еквіваленти (/v1/chart, /v1/synastry тощо) для аналогічного контенту без PDF-рендеру.

2026-02-19 · Авторизація через Google і GitHub (+2 ендпоінти)

Один акаунт на всю екосистему - користувач, який реєструвався на astroway.info або app.astroway.info, входить у developer console через ту саму пошту/SSO, бачить історію замовлень, кредити й API-ключі.

• GET /v1/auth/oauth/google/start?return=<path>: стартує Google OAuth-флоу.
• GET /v1/auth/oauth/github/start?return=<path>: стартує GitHub OAuth-флоу.

Callback завершується редиректом на /dashboard/oauth/callback#access_token=&refresh_token=&user= - далі дашборд персистить токени як після /v1/auth/login. Якщо email уже зареєстрований через звичайну форму та email_verified=true від провайдера - обліковий запис лінкується, новий не створюється.

2026-02-17 · Reports Pack ($99 / 500 000 кредитів) + white-label включено

Тариф для розробників PDF-репортів - 100 PDF/міс за $0.99 ефективно, з white-label за замовчуванням:

• Тариф reports_pack ($99/міс або $990/рік) дає 500 000 кредитів і 200 запитів/хв.
• Доступ обмежений до /reports/* (12 типів PDF: natal, synastry, child, business, career, love, money, transit-yearly, vedic-kundli, lal-kitab, human-design, tarot) + /whitelabel/* (індивідуальний логотип + кольори + домен). Все інше повертає 402 PLAN_PACK_MISMATCH (upgrade_to: pro).
• White-label включено як стандарт: не потрібен апгрейд до Enterprise для брендованих PDF.
• Перевитрата $3 / 10 000 кредитів (як Pro), перемикач обмеження витрат доступний.
• 21 локалізація PDF, формат A4, доставка через signed-URL CDN (TTL 24 год).

API plan enum тепер: free | indie | starter | pro | business | enterprise | hd_pack | esoteric_pack | vedic_pack | reports_pack. Новий WC slug: astroway-api-reports-pack.

2026-02-15 · Крос-школа: Jaimini yogas + Lal Kitab та KP doshas (+17 ендпоінтів)

Сімнадцять ендпоінтів - закривають вертикаль крос-школи для йог та дош.

• Jaimini Yogas (5): /vedic/yogas/jaimini/{raja, dhana, daridra, viparita, full}. Базуються на chara karakas (AK / Amk / PK).
• Lal Kitab dosha varianti (6): /vedic/doshas/lal-kitab/{manglik, kalsarpa, pitra, shrapit, rin, full}. LK-специфічні відмінення та upayas.
• KP dosha varianti (6): /vedic/doshas/kp/{manglik, kalasarpa, pitra, sade-sati, kemadruma, full}. BPHS-правила + KP sub-lord chain. Sade Sati - transit-aware (потребує targetDate).

Sources: Jaimini Sutras 2.x + Sanjay Rath, K. Ashant + R.D. Mathur, K.S. Krishnamurti Reader I-VI. Pricing: TIER_3 (50 кредитів).

2026-02-13 · Vedic Pack ($19 / 100 000 кредитів)

Окремий тариф для Vedic-астрології - 165 ендпоінтів за ціною Starter:

• Тариф vedic_pack ($19/міс або $190/рік) дає 100 000 кредитів і 100 запитів/хв.
• Доступ обмежений до Vedic namespaces (/vedic/*, /nakshatras, /ashtakavarga, /vedic-divisional). Всі інші ендпоінти повертають 402 PLAN_PACK_MISMATCH.
• Покриття: 16 vargas D1-D60, panchang (7), shadbala (7), yogas (7), doshas (7), compatibility ashtakoot (6), muhurat (12 категорій), 8 систем dasha × 5 рівнів (40), KP, Lal Kitab, Jaimini.
• 2.5-5× більше карт за ту ж ціну, що Prokerala Ruby (~5K kundlis/міс vs їх 1-2K).

API plan enum тепер: free | indie | starter | pro | business | enterprise | hd_pack | esoteric_pack | vedic_pack. Новий WC slug: astroway-api-vedic-pack.

2026-02-09 · Lal Kitab: повний пакет (+12 ендпоінтів)

Дванадцять ендпоінтів North-Indian Vedic школи на основі anonymous Urdu MSS 1939-1952. Ціла школа - YELLOW (intrinsic - single-school з розходженнями між modern авторами).

• /vedic/lal-kitab/teva: fixed-house chart (house = sign).
• /vedic/lal-kitab/lal-kundali: 12-house grid layout.
• /vedic/lal-kitab/kismat + /prosperity: fortune & dhana yoga scoring.
• /vedic/lal-kitab/dasha (35y) + /varshphal + /life-graph: timing.
• /vedic/lal-kitab/debts: 6 Rin (Pitri/Stree/Kanya/Atma/Rishi/Daiva) detection + remedy.
• /vedic/lal-kitab/remedies: per-planet upayas (день / mantra / donation).
• /vedic/lal-kitab/{planet-house-effect, blind-house, sleeping-house}.

Disclaimer surfaced у responses. Sources: K. Ashant Vol I-VI + R.D. Mathur + U.C. Mahajan.

2026-02-06 · Esoteric Pack ($9 / 200 000 кредитів)

Новий додатковий тариф для розробників езотерики/дивінації - 180 ендпоінтів за $9/міс:

• Тариф esoteric_pack ($9/міс або $90/рік) дає 200 000 кредитів і 60 запитів/хв.
• Доступ обмежений до просторів esoteric/divination (/tarot/*, /numerology/*, /reference/*, /esoteric/*, /geomancy/*, /runes/*, /palmistry/*, /iching*, /sabian-symbols, /destiny-matrix/ladini, /djamaspa). Усі інші ендпоінти повертають 402 PLAN_PACK_MISMATCH.
• Не комбінується з іншими тарифами на одному ключі: це окреме розширення за аналогією з HD Pack.

API plan enum тепер: free | indie | starter | pro | business | enterprise | hd_pack | esoteric_pack. Нові WC slug-и: astroway-api-esoteric-pack (місячна + річна варіації). Якщо ви створювали ключі через /v1/keys без явного plan - нічого не змінюється.

2026-02-02 · BaZi + Zi Wei Dou Shu (+17 ендпоінтів)

Третя китайська категорія, після Chinese Zodiac + Feng Shui:

• BaZi (5): /bazi/{year-pillar, month-pillar, four-pillars, element-balance, year-pillar-decade}. Year + month pillars канонічні, day + hour pillars відкладено до cross-verification з Hong Kong Observatory (різні джерела дають різні JD-якорі).
• Zi Wei Dou Shu MVP (12): /ziwei/{twelve-palaces, main-stars, full-chart, palace-destiny, palace-siblings, palace-spouse, palace-children, palace-wealth, palace-health, palace-travel, palace-career, palace-property}. MVP - palace meanings + 14 main stars list. Повний chart відкладено (потрібна спеціалізована lunar-month ephemeris).

API now exposes 505 endpoints - паритет з ширшим конкурентом (Astrology-API.io).

2026-01-30 · Wellness (+9 ендпоінтів)

Дев’ять wellness-ендпоінтів - медична астрологія + дієта + йога + кристали тощо. Educational use only - not medical advice, дисклеймер у кожній відповіді.

• POST /v1/wellness/medical-astrology: body-rulership за традиційним Melothesia.
• POST /v1/wellness/diet: їжа за елементом (focus / emphasize / avoid).
• POST /v1/wellness/yoga: фокус + асани + пранаяма за знаком.
• POST /v1/wellness/exercise: інтенсивність + recommended/avoid за елементом.
• POST /v1/wellness/mental-health: element-profile дзеркала + dominantElement + сильні/слабкі сторони + coping.
• POST /v1/wellness/sleep-cycles: поради сну по фазах Місяця.
• POST /v1/wellness/herbs: трави за планетарним правителем знака (Culpeper 1653).
• POST /v1/wellness/crystals: кристали за знаком + інтенції.
• POST /v1/wellness/cycle: age-based wellness milestones (Saturn return, Uranus opposition, …).

Sources: Pelletier 1978 + Culpeper 1653 + Judy Hall Crystal Bible. Tier - 2 кредити (cycle = 1 кредит).

2026-01-27 · Mayan calendars (+8 ендпоінтів)

Майянський блок: класичний Tzolkin + Haab + Long Count + Calendar Round + Lord of the Night, плюс Dreamspell (модерн Argüelles 1990).

• POST /v1/mayan/tzolkin: 260-денний sacred calendar (число 1-13 + ім’я з 20).
• POST /v1/mayan/haab: 365-денний civil calendar (18 місяців × 20 + 5-денний Wayeb).
• POST /v1/mayan/long-count: 5-place позиційна нотація baktun.katun.tun.uinal.kin.
• POST /v1/mayan/calendar-round: комбінований Tzolkin+Haab (52-річний цикл).
• POST /v1/mayan/lord-of-night: 9-денний цикл (G1-G9).
• POST /v1/mayan/full: все класичне в одному виклику.
• POST /v1/mayan/compatibility: сумісність пари за tone/name/element/direction.
• POST /v1/mayan/dreamspell: модерн Argüelles (kin 1-260, tone × seal).

Source: Goodman-Martínez-Thompson correlation (Thompson 1935 + Lounsbury 1976). Validation anchor: 2012-12-21 = Long Count 13.0.0.0.0 ✓ (Bak’tun rollover).

2026-01-23 · Sthira + Shoola Dasha (+10 ендпоінтів)

Дві Jaimini-школи rasi-dasha з повним cascade (maha, antar, pratyantar, sookshma, prana):

• Sthira: seed = знак Brahma planet, MD forward 12 знаків (7y movable / 8y fixed / 9y dual).
• Shoola: seed = stronger_rasi(asc, asc+6), MD forward 12×9y, опція antardasaSeedOption ∈ 3.

Закриває набір 10 dasha-шкіл × 5 рівнів = 50 ендпоінтів. Sources: BPHS Adhyayas 49-50 + Jaimini Sutras 2.x.

2026-01-19 · Pet + Business + Financial (+36 ендпоінтів)

Три категорії одним shipment:

• Pet (14): /pet/{birth-chart, sun-sign-meaning, personality, temperament, training-style, diet-by-sign, grooming-by-element, exercise-needs, communication-style, play-style, health-tips, best-names, lucky-day, owner-pet-compatibility}. Disclaimer: entertainment only - not vet care.
• Business (12): /business/{founder-personality, leadership-style, ideal-industry, founding-chart, electional-day, name-suggestions, team-compatibility, customer-archetype, marketing-style, risk-profile, ideal-partner-sign, expansion-timing}. Disclaimer: strategic ideation, не правова/податкова порада.
• Financial (10): /financial/{investor-archetype, risk-tolerance, spending-style, savings-tips, career-money-style, wealth-house, lucky-numbers, lucky-day, market-timing, wealth-cycle}. ⚠️ NOT INVESTMENT ADVICE - посилений disclaimer у кожній відповіді.

Tier - 2 кредити (Financial market-timing/wealth-cycle = 3 кредити).

2026-01-16 · Jaimini analysis suite (+10 ендпоінтів)

Десять Jaimini-аналітичних ендпоінтів - chara/naisargika karakas, padas (A1..A12 + S1..S12 + M1..M12 + graha arudhas), Upapada, rasi/graha drishti, Karakamsa (AK у D9), running dasha summary, basic Jaimini yogas.

Sources: Jaimini Sutras 1-2 + BPHS Adhyayas 26/47.

2026-01-09 · Status page + AI-агенти + дефолтний base URL

• Публічна status page: https://api.astroway.info/status: uptime, latency p50/p95/p99, кешовано 60s.
• llms.txt for AI agents: https://api.astroway.info/llms.txt: структуровані інструкції для Claude / ChatGPT / Perplexity Code agents.
• Дефолтний base URL у документації, MCP server, SDKs, Postman collection - api.astroway.info/v1 (з 301 редіректом зі старого api-calc.astroway.info).

2025-12-30 · Tribhagi, Shatabdika, Shodashottari Dashas (+15 ендпоінтів)

Три nakshatra-dasha системи з full cascade:

• Tribhagi: 1/3-scale Vimshottari (40-year cycle).
• Shatabdika: 100-year cycle, 7 планет (без shadow).
• Shodashottari: 116-year cycle, 8 планет (без Rahu).

Sources: BPHS Adhyaya 46.

2025-12-25 · Кредитні плани: 5-tier rebalance + Free 5K → 10K

Перекалібровано кредитні tiers після 18-competitor audit. Free план тепер дає 10 000 кредитів на місяць (було 5 000). Проценти витрат для типових use-cases (натальна карта + 7 транзитів) знижено на ~22%. Жодних breaking-змін у API - лише економіка.

2025-12-17 · Chinese Zodiac + Feng Shui Kua (+8 ендпоінтів)

Перший блок китайської астрології, базовий шар (BaZi + Zi Wei Dou Shu - далі):

• POST /v1/chinese/zodiac/animal: тварина року + повний pillar (Geng-Wu, Wood-yang, тощо).
• POST /v1/chinese/zodiac/element: фіксований + циклічний елемент Wu Xing з yin/yang.
• POST /v1/chinese/zodiac/inner-animal: внутрішня тварина (бранч місяця).
• POST /v1/chinese/zodiac/secret-animal: таємна тварина (бранч години: потрібен time).
• POST /v1/chinese/zodiac/compatibility: сумісність пари за San He трина / Liu Chong конфлікт-парами.
• POST /v1/chinese/feng-shui/kua: персональне Kua-число + East/West-group.
• POST /v1/chinese/feng-shui/lucky-directions: 4 щасливі + 4 нещасливі компасні напрямки.
• POST /v1/chinese/feng-shui/bagua: Bagua-карта 9 життєвих сфер з елементами + кольорами.

Source: 60-jiazi canonical + L. Skinner Living Earth Manual (1976) + Lillian Too. Pricing tier - 2 кредити за виклик. Lichun cutoff = Feb 4 (точність ±1 день для 1900–2100).

2025-12-09 · Quality pass: 24 bug fixes у Vedic категоріях

Фіксація 24 розрахункових багів через 6 паралельних deep-research-агентів. Найкритичніші: Mangal dosha cancellation (own/exalted Mars cancels per BPHS), Pitru dosha trigger (Sun-Saturn vs Sun-Rahu), composite Davison ARMC drift, ACG meridian-line accuracy. Snapshot-тестів додано: 47.

2025-12-02 · Vedic Compatibility + Muhurat (+18 ендпоінтів)

• Compatibility (6): Ashta-Koota matching (Varna/Vasya/Tara/Yoni/Graha-Maitri/Gana/Bhakoot/Nadi) + Mangal dosha compat + Bhrigu summary.
• Muhurat (12): електив для марriage, business, journey, education, surgery, наречений, mahurta-types (abhijit, vijaya, amrit, brahma).

Sources: BPHS + Muhurta Chintamani.

2025-11-29 · KP (Krishnamurti Paddhati): повний пакет (+10 ендпоінтів)

Десять ендпоінтів канонічної KP-школи (K.S. Krishnamurti 1971).

• /vedic/kp/{cusps, sub-lords, planet-cuspal-position}: Placidus cusps + 4-level sub-lord chain (sign / star / sub / sub-sub).
• /vedic/kp/ruling-planets: Day/Hora + Asc + Moon chain, deduplicated.
• /vedic/kp/horary: KP horary number 1..249 → ASC longitude lookup.
• /vedic/kp/significators: primary / secondary / tertiary per planet.
• /vedic/kp/sub-sub-lord: chain at arbitrary sidereal longitude.
• /vedic/kp/asc-sub: Ascendant sub-lord.
• /vedic/kp/fortuna: Part of Fortune (day/night) + KP chain.
• /vedic/kp/transit-kp: current-moment positions + KP chain.

Алгоритм: Vimshottari proportional sub-divisions (27 stars × 9 sub-lords). Sources: K.S. Krishnamurti Reader I-VI (1971-77).

2025-11-22 · Vimshottari + Yogini + Ashtottari + Kalachakra Dashas (+20 ендпоінтів)

Чотири класичні Vedic dasha-системи з повним cascade (maha, antar, pratyantar, sookshma, prana):

• Vimshottari: 120-year cycle, 9 планет.
• Yogini: 36-year cycle, 8 yoginis.
• Ashtottari: 108-year cycle, 8 планет (без Ketu), Ardradi tradition.
• Kalachakra: sign-based dasha, paramayu варіює per pada (100/85/83/86).

Sources: BPHS Adhyaya 46 + Saravali. Cross-validated проти PyJHora 7.02.

2025-11-08 · Chara Dasha (Jaimini K.N. Rao) (+5 ендпоінтів)

Rasi-dasha школи Jaimini у варіанті K.N. Rao (1995). Direction = forward для рухомих/двоїстих знаків лагни, reverse - для фіксованих. Co-lord rule для Скорпіона (Mars+Ketu) і Водолія (Saturn+Rahu).

2025-10-25 · MCP-сервер + AI gateway

• MCP-сервер @astroway/mcp - Model Context Protocol для Claude Desktop, Cursor, Cody. Кожен ендпоінт API доступний як MCP tool.
• AI gateway: окремий приватний микросервіс ai.astroway.info обробляє LLM-запити з провайдерною ланкою (Gemini Flash → Groq Llama → OpenRouter → Cerebras → SambaNova → Mistral).
• TypeScript SDK очікується окремим релізом: поки що використовуйте OpenAPI codegen за https://api.astroway.info/v1/openapi.json (openapi-typescript / openapi-fetch дають типизованого клієнта з 612 типизованих request/response пар).

2025-10-08 · Vedic Yogas + Doshas Parashara (+14 ендпоінтів)

• Yogas (7): Raja, Dhana, Dharma-Karmadhipati, Pancha-Mahapurusha, Gajakesari, Adhi + composite.
• Doshas (7): Mangal, Kaal Sarp, Pitru, Shrapit, Grahan, Guru-Chandal + composite.

Sources: BPHS Adhyayas 36-39, Phaladeepika.

2025-08-10 · Vedic Vargas D1-D60 + Panchang + Shadbala (+31 ендпоінт)

• 16 Vargas D1-D60 (16): від Rasi (D1) до Shashtiamsa (D60), per BPHS Adhyaya 7.
• Panchang (8): tithi, vara, nakshatra, yoga, karana + sunrise/sunset, abhijit, rahu kaal.
• Shadbala (7): 6 sources of strength per planet + composite (Sthana, Dig, Kala, Cheshta, Naisargika, Drig).

2025-05-18 · Esoteric dictionaries + Crystal/Angel/Dream (+30 ендпоінтів)

Розширення reference-словників: 15 esoteric понять (chakras, koshas, tattvas, gunas) + 15 crystal/angel/dream lookup tables. Cached на edge (Cloudflare R2).

2025-03-12 · Reference glossary + Tarot Lenormand (+24 ендпоінти)

• Reference (14): словники signs, planets, houses, aspects, nakshatras, fixed stars, Sabian symbols.
• Tarot Lenormand (10): 36-card system: single, 3-card, 9-card, Grand Tableau, by-question.

2024-11-15 · Tarot Marseille (+20 ендпоінтів)

20 ендпоінтів Marseille deck: spreads (single, 3-card, Cross, 5-card, Celtic Cross, year-ahead), card meanings, reversed mode, by-question. Sources: Camoin / Jodorowsky public references.

2024-08-25 · Numerology, повний пакет: Pythagorean + Chaldean + Kabbalistic + Vedic (+40 ендпоінтів)

Чотири нумерологічні системи × 10 ендпоінтів кожна: life path, expression, soul urge, personality, birthday, maturity, current personal year/month/day, name compatibility.

Sources: Pythagorean (Cheiro 1908), Chaldean (Cheiro), Kabbalistic Hebrew gematria, Vedic Chaldean Indian.

2024-05-08 · Tarot Rider-Waite-Smith (+35 ендпоінтів)

35 ендпоінтів RWS deck: усі канонічні spreads (single, 3-card, Celtic Cross, year-ahead, relationship, 5-card horseshoe, 7-card ellipse, decision, situation, monthly), card meanings (upright + reversed), by-question, daily card, deck shuffle.

Sources: Smith images PD since 2021, Waite “Pictorial Key” 1909 PD.

2024-02-20 · AI horoscope generation + interpretations (+12 ендпоінтів)

Генерація natural-language інтерпретацій:

• /horoscope/{daily, weekly, monthly}: текстові гороскопи.
• /interpret/{natal, transit, synastry, compatibility}: детальні інтерпретації.

Провайдерна ланцюжок: GPT-4 → Anthropic Claude → fallback Groq.

2023-11-28 · Destiny Matrix (Ladini) (+1 ендпоінт)

/destiny-matrix/ladini - система Natalia Ladini (Russian/CIS market). Single-author method з явним disclaimer.

2023-09-20 · Aspects timeline + harmonics + cyclic index (+12 ендпоінтів)

Розширений aspect-аналіз:

• /aspect-timeline: точні моменти aspects на N днів вперед.
• /harmonics/{2..12}: гармонійні карти.
• /cyclic-index: Андре Барбо’s cyclic index of social tensions.
• /sabian-symbols: Marc Edmund Jones 360 symbols.

2023-05-10 · Astrocartography + Local Space + Geodetic (+18 ендпоінтів)

Geo-астрологія:

• /acg + /acg-zones: Astrocartography ліній планет.
• /local-space: Local Space horizon.
• /parans: параны (Bernadette Brady).
• /relocation: relocation chart.
• /zenith + /horizon + /geodetic: додаткові geo-engines.
• /ccg-analysis: CCG/CMG детальна geo-аналіз.

Sources: Jim Lewis Astro*Carto*Graphy, Sepharial Theory of Geodetic Equivalents, Bernadette Brady.

2023-02-15 · Human Design module (+12 ендпоінтів)

Повний Human Design engine:

• /human-design: bodygraph (gates, channels, centers, type, profile, authority, strategy, environment, perspective).
• /hd/incarnation-cross: incarnation cross + 4 gates.
• /hd/{channels, gates, profiles, definition, authority, strategy, environment, perspective, mental-projector, etc}.

Sources: Ra Uru Hu The Human Design System + Chetan Parkyn + Lynda Bunnell.

2022-08-20 · Серверні synastry + composite

Реляційна астрологія (synastry, composite, Davison) реалізована на сервері. Першими доступні через /v1/synastry, /v1/composite, /v1/davison. Маркер розширення до релаційного аналізу.

Валідовано проти Solar Fire / Astrodienst - drift у межах похибки методу (≤0.5″ на середньостатистичному обчисленні).

2022-07-28 · Synastry, composite, Davison + group synastry (+5 ендпоінтів)

• /synastry: relationship comparison з aspects matrix.
• /composite: Robert Hand midpoint composite.
• /davison: Ronald Davison time-place composite.
• /group-synastry: multi-person (3+) synastry матриця.

Sources: Hand Planets in Composite, Davison Synastry, Lois Sargent.

2022-04-15 · app.astroway.info SPA, споживчий продукт live

Запущено app.astroway.info - SPA на React/TypeScript, що звертається до бекенда через /v1/*. Користувацькі акаунти, збережені карти, обране. Маркер переходу від тільки-сайту до повноцінного продукту.

Цей же бекенд згодом стає базою публічного API.

2022-03-18 · Essential dignities + receptions + almuten + arabic parts (+13 ендпоінтів)

Класична астрологія:

• /essential-dignities: domicile, exaltation, triplicity, terms, faces.
• /receptions: mutual reception detection.
• /almuten: Almuten Figuris (chart ruler).
• /arabic-parts: Lots of Fortune, Spirit, Eros, Necessity та інші 30+ Hellenistic lots.
• /hyleg: hyleg + alcocoden.
• /algol-minimum + /fixed-stars: fixed stars.

Sources: Lilly Christian Astrology + Brennan Hellenistic Astrology.

2021-08-10 · Transit calendar + forecast calendar + phase return (+10 ендпоінтів)

• /transit-calendar: точні моменти transits на 6/12 місяців вперед.
• /forecast-calendar: щомісячні forecasts.
• /phase-return: solar return, lunar return, Saturn return, Jupiter return.
• /eclipse-analysis: eclipses у contextі natal chart.

2021-04-05 · Aspects calculation + house systems expansion (+8 ендпоінтів)

• /aspects: повна aspects matrix з orb tables (Ptolemy, modern, asteroid).
• /coalescent: coalescent points.
• /disposition-chains: planet rulership chains.
• House systems expansion: Placidus, Koch, Equal, Whole, Campanus, Regiomontanus, Topocentric, Porphyry, Alcabitius, Morinus.

2020-07-10 · Aspects matrix + класичні аспекти

Стабілізовано суть calculation suite. /v1/aspects готовий: підтримка conjunction, opposition, square, trine, sextile з птолемеївськими орбами. Фундамент для всієї подальшої аналітики (transits, synastry, returns).

WASM-збірка Swiss Ephemeris остаточно інтегрована - ~5x швидше за раніше використовувану аналітичну модель.

2020-06-15 · Daily/weekly horoscope text (+4 ендпоінти)

• /horoscope/daily/{sign}: щоденний гороскоп для кожного знаку.
• /horoscope/weekly + /horoscope/monthly: тижневі / місячні.
• /sun-signs: sun-sign meanings.

Текст генерується manual editorial team (LLM-augmented texts came later у 2024).

2020-03-20 · Synastry beta + ephemeris extras (+5 ендпоінтів)

• /synastry-beta: initial synastry (повний релиз 2022).
• /ephemeris/{planets, asteroids, lunar-nodes}: historical 1900-2100.
• /extra: fixed stars, Black Moon Lilith, Chiron.

2020-02-20 · REST API skeleton + OpenAPI 2.0

Опубліковано внутрішню специфікацію OpenAPI 2.0. Перший namespace /v1/*. Аутентифікація через X-Api-Key-заголовок. Rate-limiting infrastructure готова.

Internal milestone - публічний API запуститься пізніше, але контракт стабільний з цього моменту.

2019-12-15 · Internal /chart calculation engine

Перша серверна реалізація /chart (приватна). Placidus-доми, sidereal-офсети, обчислення планет, фіксованих зір. Тестування проти Astro.com baseline.

Повністю Node.js - від попередньої PHP-only логіки відмовляємось остаточно.

2019-09-25 · Initial release

Перший публічний випуск AstroWay Astrology API. Базовий функціонал:

• /chart: натальна карта (планети, доми, ascendant, MC).
• /transit: поточні транзитні позиції.
• /aspects: основні aspects (conjunctions, oppositions, squares, trines, sextiles).
• /horoscope: щоденний гороскоп (за sun sign).
• /ephemeris: ефемериди для будь-якої дати.
• /health: health check.

OpenAPI 2.0 specification, REST/JSON, X-Api-Key authentication. Backend on Swiss Ephemeris. Free tier - 1000 requests / month.

2019-09-01 · Інтеграція Swiss Ephemeris, фундамент

Бібліотеку Swiss Ephemeris 2.x інтегровано в бекенд astroway.info. Sub-arcsecond точність планетарних позицій, лунарних вузлів, астероїдів у межах 1900–2100.

Усі наступні розрахункові ендпоінти спираються на цей шар. Та сама бібліотека, що в Solar Fire, Kepler, Astro Gold, Astrodienst.