Changelog що нового

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).