AstroWay/api v2.190.0 · blog
усі системи в нормі

Jaimini-розширення: 5 нових ендпоінтів для глибокої Vedic-аналітики

П'ять нових ендпоінтів сімейства /v1/vedic/jaimini/* для глибокого аналізу за школою Jaimini - chara-karaka сканер, karakamsa-проекція, функціональна природа грах, atmakaraka-rotation timeline та повний argala/virodhargala скан. Канонічні джерела: Sanjay Rath, BPHS A.34.

Jaimini Sutras - окрема школа Vedic-астрології з власним інструментарієм поверх стандартної Parashara-системи: chara karakas замість фіксованих сигніфікаторів, dasha-системи на знаках, padas, argala. Майже всі публічні astrology-API обмежуються Parashara-set’ом - ми додаємо п’ять Jaimini-специфічних ендпоінтів, які раніше були відкладені як deep-niche features.

Усі п’ять - повноцінні ендпоінти з регресійними snapshot-тестами, не AI-обгортки.

1. Karaka Yoga скан: /v1/vedic/yogas/jaimini/karaka-yoga

Section titled “1. Karaka Yoga скан: /v1/vedic/yogas/jaimini/karaka-yoga”

Chara karakas (рухливі сигніфікатори) - це 8 планет, відсортованих за градусом у знаку (без врахування знака): Atmakaraka, Amatyakaraka, Bhratrukaraka, Matrukaraka, Putrakaraka, Gnatikaraka, Darakaraka, та optional 8-я. Endpoint сканує всі 8 з оцінкою сили розміщення (kendra / trine / dusthana) і повертає manifestation hint на кожну.

Terminal window
curl -X POST https://api.astroway.info/v1/vedic/yogas/jaimini/karaka-yoga \
-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
}'

Use case. Будуєте Vedic-консультаційний продукт - клієнт хоче дізнатись “хто я по душі / по професії / по партнеру”. Karaka Yoga відразу повертає 8 нативних осей з placement score, не треба самому витягувати planets array і сортувати за градусом.

2. Karakamsa: /v1/vedic/yogas/jaimini/karakamsa

Section titled “2. Karakamsa: /v1/vedic/yogas/jaimini/karakamsa”

Karakamsa Lagna - це знак, у якому стоїть Atmakaraka в D9 Navamsha. Від нього будується повна 12-будинкова проекція з канонічними значеннями кожного будинку: 1-й - iṣṭa devata (особистий бог), 5-й - мантри/духовна practice, 12-й - мокша і занедбана карма.

Terminal window
curl -X POST https://api.astroway.info/v1/vedic/yogas/jaimini/karakamsa \
-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 }'

Response містить повну 12-будинкову розбивку з планетами в кожному будинку, значення per будинок, та підказку домінантної теми (наприклад, “spiritual” vs “material” нативу) - на основі того, які планети populate-нути ключові будинки 1/5/9/12.

Сорс правил. Канонічні signification-и по karakamsa беруться з коментаря Sanjay Rath до Jaimini Sutras. Це не наша інтерпретація - це cited tradition.

3. Shubha Graha: /v1/vedic/yogas/jaimini/shubha-graha

Section titled “3. Shubha Graha: /v1/vedic/yogas/jaimini/shubha-graha”

Стандартна Parashara-аналітика дає “natural benefic / malefic” - Jupiter завжди benefic, Saturn завжди malefic. Це базовий рівень. Функціональна natura залежить від володіння будинками від Lagna конкретного нативу. Endpoint повертає категорію для кожної з 7 видимих грах:

  • yogakaraka: володіє і kendra, і trine водночас (наприклад, Mars для Cancer Lagna)
  • functional-benefic: володіє trine (5/9)
  • neutral: інші конфігурації
  • functional-malefic: володіє dusthana (6/8/12)
  • maraka: володіє 2/7, потенційний killer-signifier

Правила взяті з BPHS A.34 - Kendradhipati Dosha + Maraka rules.

Terminal window
curl -X POST https://api.astroway.info/v1/vedic/yogas/jaimini/shubha-graha \
-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 }'

Use case. Перед тим як трактувати dasha-період, треба знати чи планета періоду - yogakaraka чи maraka для конкретного нативу. Цей endpoint дає той context за один виклик, без ручного маппингу house-rulership.

4. Atmakaraka Rotation: /v1/vedic/jaimini/atmakaraka-rotation

Section titled “4. Atmakaraka Rotation: /v1/vedic/jaimini/atmakaraka-rotation”

Atmakaraka - найвища планета за градусом у знаку - формально статична. Але через символічну прогресію 1°/рік позиції всіх chara karakas повільно зсуваються, і в певні роки Atmakaraka змінюється (планета з меншим градусом обганяє формального лідера через символічний рух).

Endpoint повертає timeline таких переходів через все життя - корисно для life-mission narrative.

Terminal window
curl -X POST https://api.astroway.info/v1/vedic/jaimini/atmakaraka-rotation \
-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 }'

Response - масив подій з age_at_transition, planet_before, planet_after. Це Tier 3 (50 credits) - time-series compute дорожчий за разовий снепшот.

5. Argala Analysis: /v1/vedic/jaimini/argala-analysis

Section titled “5. Argala Analysis: /v1/vedic/jaimini/argala-analysis”

Argala (запор, “intervention”) - Jaimini-механізм підтримки/блокування будинку через занятість певних дистанцій. Повний скан:

  • Primary Argala: 2/4/11 від цільового будинку
  • Secondary Argala: 5 від цільового будинку
  • Special Argala: 8 від цільового будинку
  • Virodhargala (опозиція до argala): 12/10/3 primary, 9 secondary, 6 special

Endpoint повертає net-influence на кожен з 12 будинків + dominant-over (хто домінує - argala чи virodhargala) для кожного будинку.

Terminal window
curl -X POST https://api.astroway.info/v1/vedic/jaimini/argala-analysis \
-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 }'

Use case. Hard-mode Vedic consultant interpreter. Перед прогнозом на будинок - перевірити: чи argala-конфігурація підтримує тему, чи virodhargala блокує. Це той рівень аналітики, який зазвичай вимагає 30+ хвилин ручної роботи в Jagannatha Hora - тут отримуєте структурований response.

EndpointTierCredits
karaka-yogaTier 220
karakamsaTier 220
shubha-grahaTier 220
atmakaraka-rotationTier 350
argala-analysisTier 220

Усі п’ять доступні через Vedic Pack add-on ($9/міс понад базовий тариф). Поодинокі виклики також працюють у Pay-as-you-go.

Усі п’ять схем - у /v1/openapi.json. Наступний codegen-реліз SDK (TS / Python / PHP) додасть типізовані методи під namespace vedic.jaimini.*. Дорожні мапи - у відповідних staging-репо.

Vedic-сегмент у developer-tooling сильно underbuilt: майже всі публічні API дають максимум Vimshottari + planets-in-signs. Хто хоче Jaimini - мусить інтегрувати окремий desktop-софт (Jagannatha Hora, Parashara’s Light) або писати свій SwissEph-wrapper.

Ці п’ять ендпоінтів закривають конкретний gap - школа Jaimini тепер consumable через HTTP так само як натальна карта. Документація для кожного - у /docs/api/ → Vedic.

MakSeong · AstroWay

Роблю AstroWay API: загортаю Swiss Ephemeris у чистий REST і пишу про нудні деталі, які насправді важливі.

// побудуй на цьому

Той самий Swiss Ephemeris, що й у Solar Fire - у 4 рядках коду.

Безкоштовний ключ без картки. 5 000 викликів на місяць до першої оплати.

Більше з блогу усі дописи →

Ephemeris 2026-07-19

Як ми тримаємо точність під контролем: CI проти swetest і NASA

Точність в астро-API легко деградує від одного рефакторингу ефемерид. Розбираємо захист: одне ядро Swiss Ephemeris на браузер і сервер, сотні заморожених снапшотів на еталонних картах і триангуляція кожного PR проти swetest CGI, Kerykeion, Prokerala та каталогу затемнень NASA.

Engineering 2026-07-15

Три офіційні SDK: TypeScript, Python, PHP замість сирого curl

Сирий HTTP працює, але типізований клієнт економить години: автодоповнення шляхів, типи запиту й відповіді, вбудований retry на 408/409/429/5xx і Stainless-style ієрархія помилок. Розбираємо три офіційні SDK - @astroway/sdk (npm), astroway (PyPI), astroway/sdk (Packagist) - і чим вони згенеровані з одного OpenAPI-контракту.

Engineering 2026-06-05

X-Cache header: видимий cache-status для оптимізації клієнтських інтеграцій

Кожна response API тепер несе X-Cache: MISS | HIT | BYPASS - клієнт відразу бачить чи запит обчислений з нуля, чи витягнутий з кешу. Це відкриває cache hit % колонку в /dashboard/usage та дозволяє оптимізувати інтеграцію без guesswork.