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

Rectification API: корекція часу народження для розробників

Ректифікація - це процес уточнення невідомого або неточного часу народження за подіями життя. У цьому пості - як автоматизувати її через API з використанням алгоритмічного методу та Trutine of Hermes.

Більшість користувачів астрології знають дату народження, але не знають точний час. Різниця в 30 хвилин може зсунути асцендент на 5+ градусів - і це змінює положення домів та аспекти. Для серйозної астрологічної роботи це важливо.

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

У цьому пості - коли застосовувати ректифікацію, як працюють алгоритми та як інтегрувати її у свій застосунок.

Ректифікація - це корекція часу народження. Ти починаєш з приблизного часу (наприклад, «ранок» чи «близько 14:00») і звужуєш його, використовуючи:

  • Важливі події життя (одруження, діти, зміна кар’єри, смерті)
  • Фізичні характеристики (класична астрологія мапить знак асцендента на типи тіла)
  • Кутові позиції планет при народженні

На виході - уточнений час народження, зазвичай у межах ±5 хвилин від реального.

1. Trutine of Hermes (/v1/rectification/trutine) - 250 кредитів

Section titled “1. Trutine of Hermes (/v1/rectification/trutine) - 250 кредитів”

Класичний метод, приписаний Гермесу Трисмегіста. Використовує зв’язок між позицією Місяця у момент народження та асцендентом / десцендентом у момент зачаття (~9 місяців раніше).

Як це працює:

  1. Беремо приблизну дату народження
  2. Розраховуємо діапазон дат зачаття (260–290 днів раніше)
  3. Для кожної кандидатної дати зачаття перевіряємо, чи відповідає позиція Місяця при народженні асценденту / десценденту в момент зачаття
  4. Повертаємо список кандидатних часів народження, відсортованих за fit’ом

Швидко, але менш точно. Добре для звуження широкого вікна (наприклад, «ранок» → 2-годинне вікно).

const result = await client.rectification.trutine({
date: '1990-07-14',
time: '14:30:00',
timezoneOffset: 3,
latitude: 50.4501,
longitude: 30.5234,
});
console.log(`Suggested ascendant: ${result.suggestedAsc.toFixed(2)}°`);
console.log(`Moon above the horizon at conception: ${result.moonAboveHorizon}`);

2. Повна ректифікація (/v1/rectification) - 500 кредитів

Section titled “2. Повна ректифікація (/v1/rectification) - 500 кредитів”

Алгоритмічний підхід на основі кількох подій життя. Це важкий варіант (до 120 с на запит).

Вхід:

  • Приблизний час народження (діапазон)
  • Список подій життя з датами та типами
  • Опційно: фізичний опис

Алгоритм:

  1. Генерує кандидатні часи народження всередині діапазону (зазвичай з кроком 1 хвилина)
  2. Для кожного кандидата рахує натальну карту
  3. Скорує кожного, наскільки події збігаються з передбачуваними астрологічними патернами (прогресії, дирекції, транзити)
  4. Повертає топ-кандидатів із оцінками впевненості
const result = await client.rectification.compute({
baseInput: {
date: '1990-07-14',
time: '14:30:00',
timezoneOffset: 3,
latitude: 50.4501,
longitude: 30.5234,
},
events: [
// type picks which significators are checked; weight is 1-3 importance
{ date: '2015-06-20', type: 'marriage', description: 'married', weight: 3 },
{ date: '2018-03-12', type: 'child', description: 'first child', weight: 2 },
{ date: '2020-09-05', type: 'career', description: 'career change', weight: 2 },
],
searchRangeMinutes: 120,
stepMinutes: 5,
});
const best = result.candidates[0];
console.log(`Best candidate: ${best.timeFormatted}, score ${best.score.toFixed(2)}, ${result.count} candidates scored`);
console.log(`Candidates: ${result.candidates.length}`);

Ректифікація цінна для:

  • Застосунків із користувачами, які не знають часу: пропонуй ректифікацію як premium-фічу
  • Професійних інструментів астролога: економить години ручної роботи на кожного клієнта
  • HD-застосунків: Human Design дуже чутливий до часу; ректифікація різко покращує точність
  • Дослідницьких застосунків: валідувати історичні карти, де записи часу неточні

Не корисна для:

  • Застосунків, де користувач уже знає час із точністю до ±5 хв (вигоди немає)
  • Казуальних гороскопних застосунків, де точність часу не впливає на вивід (щоденний sun sign її не потребує)
  • Trutine: 250 кредитів: ~1–2 секунди на запит
  • Повна ректифікація: 500 кредитів: до 120 секунд

Це найважчі ендпоінти в API. Якщо пропонуєш ректифікацію як фічу - тарифікуй відповідно: це преміум-операція, яка виправдовує вищий тариф підписки або разову покупку.

Планування бюджету:

  • 100 ректифікацій на місяць: ~50 000 кредитів = план Pro ($59) з запасом на інші виклики
  • 1 000 ректифікацій на місяць: 500 000 кредитів = Enterprise

Ректифікація забирає час. UI має:

  • Асинхронну обробку: не блокуй запит; постав його в чергу, покажи прогрес
  • Прогрес-індикатор: повний ендпоінт працює до 120 с; користувач потребує зворотного зв’язку
  • Показ результату: уточнений час, рівень впевненості, можливість перезапуску, якщо події неточні
async function handleRectify(input: RectifyInput) {
setLoading(true);
setStatus('Running rectification (this may take up to 2 minutes)...');
try {
const result = await client.rectification.compute(input);
setResult(result);
const best = result.candidates[0];
setStatus(`Done. Refined time: ${best.timeFormatted} (score ${best.score.toFixed(2)} of ${result.count})`);
} catch (err) {
setStatus(`Error: ${err.message}`);
} finally {
setLoading(false);
}
}

Поєднання з іншими ендпоінтами

Section titled “Поєднання з іншими ендпоінтами”

Типовий flow ректифікації у застосунку:

  1. Користувач вводить приблизні дані народження + події життя
  2. Застосунок спершу кличе /v1/rectification/trutine (дешево, швидко), щоб звузити вікно
  3. Потім кличе /v1/rectification (повна) з уточненим вікном для точності
  4. Застосунок кешує результат і використовує уточнений час для всіх майбутніх обчислень
  5. Майбутні виклики позначаються міткою «rectified from approximate»

Такий комбінований підхід - ~750 кредитів на повний цикл, але дає найкращу точність.

Чого очікувати від точності

Section titled “Чого очікувати від точності”

Ректифікація ніколи не дає 100% точність. Навіть професійні астрологи розходяться в оцінках на 5–10 хвилин.

Алгоритм AstroWay орієнтований на відносну точність - звужує вікно, але вивід завжди позиціонується як «найкращий кандидат», а не як гарантована істина. Завжди показуй користувачам confidence-оцінку й дай можливість перевизначити, якщо в нього є краща інформація.

Коли традиційна ректифікація кращa за алгоритм

Section titled “Коли традиційна ректифікація кращa за алгоритм”

Алгоритми - це пошук патернів. Досвідчений астролог враховує контекст, який складно закодувати: «Чи було одруження поспішним?» «Чи була зміна кар’єри добровільною?» Для карт із високими ставками комбінуй:

  1. Алгоритмічну ректифікацію: щоб звузити вікно
  2. Ручний огляд астрологом: для фінального уточнення

Твій застосунок може пропонувати це як преміум-консультацію.

AstroWay team

Інженерна команда 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.