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: siteX-RateLimit-Limit: 300X-RateLimit-Remaining: 297X-RateLimit-Counters: ip=597/600, site=297/300Формат - scope=залишок/ліміт через кому. Заголовок приходить тільки тоді, коли лічильників справді два: анонімний виклик із X-AstroWay-Site-URL. Виклик із платним ключем рахується за ключем і за тарифом, там лічильник один і заголовка немає. Він є і на відповіді 429, де потрібен найбільше.
Ліміти не змінилися. Змінилося те, що про них видно.
Що зробити з вашим кодом. Якщо ви рендерите з сервера кілька доменів з однієї адреси, читайте X-RateLimit-Counters, а не тільки X-RateLimit-Remaining: корзина сайту в кожного домену своя, а стеля на IP спільна на всі, і впирається саме вона.