Salta ai contenuti
AstroWay/api v2.254.12 · it
tutti i sistemi sono operativi

Vedic FAQ

Qui abbiamo raccolto le domande che emergono spesso quando si integrano gli endpoint vedici. Se non trovi la risposta, scrivi a hello@astroway.info e la aggiungeremo.

L’API supporta 9 ayanamsa:

CodiceNomeQuando sceglierla
lahiri (default)Chitra PakshaLo standard del governo indiano; il mercato di massa più grande. Per la maggior parte delle app vediche è questa.
ramanB.V. RamanSe integri un’app mobile per il mercato dell’India del Sud (Karnataka, Tamil Nadu).
krishnamurti (alias kp)KPSe chiami /v1/vedic/kp/*: il KP ha la sua ayanamsa.
yukteshwarSri YukteshwarDistance from Spica; theosophical / Western-leaning audiences.
fagan-bradleyFagan/BradleySiderale occidentale (non vedica). Per gli astrologi che arrivano da tradizioni sidereal-Western.
de-luceDe LuceUna scelta più vecchia degli astrologi, rara.
jn-bhasinJN BhasinUna scuola specifica, rara.
true-citraTrue Chitra PakshaSpica fissata rigidamente a 0° Bilancia. Da Lahiri differisce di 0.01°, quindi usala solo se ti serve proprio l’ancoraggio alla stella.
djwhal-khulDjwhal KhulScuola teosofica, rara. Lo scostamento più grande della tabella.

Le scuole principali differiscono poco: Lahiri, True Chitra e KP restano entro 0.1°, Fagan/Bradley, JN Bhasin, Yukteshwar e Raman fino a 1.45°. A parte stanno De Luce (3.96° da Lahiri) e Djwhal Khul (3.82°), e con queste una posizione vicina al confine di un segno passa già nel segno vicino. Misurato il 2026-08-18 sulla Luna di una singola carta; nelle tecniche basate sui gradi (Nakshatra position, Argala) la differenza si vede anche entro 0.1°.

Per impostazione predefinita gli endpoint vedici restituiscono posizioni siderali (lo zodiaco è ancorato alle stelle, con l’ayanamsa applicata). Gli endpoint occidentali (/v1/chart, /v1/synastry) restituiscono posizioni tropicali (lo zodiaco è ancorato al punto equinoziale).

Il vedico tropicale (un raro edge case proposto da Sanjay Rath ed Ernst Wilhelm) l’API non lo restituisce: tutti gli endpoint vedici calcolano in siderale e ignorano zodiacType nel body della richiesta. Le posizioni tropicali le fornisce il ramo occidentale (/v1/chart, /v1/synastry), e zodiacType: "sidereal" lo passa allo zodiaco siderale con la stessa ayanamsa.

ScuolaRegione / PubblicoPunto di forza
Parashara (BPHS)Tutto il mondo vedico: la base universaleIl corpus di tecniche più completo; si parte sempre da qui
JaiminiTamil Nadu + praticanti avanzatiPrevisioni basate sui karaka; temi di vita guidati dall’AK
Lal KitabPunjab + India del NordRimedi unici (upaya), Manglik specifico
KP (Krishnamurti)Tamil Nadu + Andhra PradeshSub-lord theory, precisione nel timing degli eventi

Pratyangira, AstroSage e le altre grandi API offrono per lo più Parashara. AstroWay copre tutte e quattro tramite gruppi di endpoint separati.

AshtakootDashakoota
RegioneIndia del Nord e del Centro, Pakistan, NepalIndia del Sud (Tamil Nadu, Karnataka, Kerala)
Scala36 punti max10 kuta (fattori)
ComponentiVarna + Vashya + Tara + Yoni + Graha Maitri + Gana + Bhakoot + NadiDina + Gana + Mahendra + Stri-Dirgha + Yoni + Rashi + Rashyadhipati + Vashya + Rajju + Vedha
API/v1/vedic/compatibility/ashtakoot/v1/vedic/compatibility/dashakoota

Se il matchmaker serve tutta l’India, chiama /v1/vedic/compatibility/full: ottieni entrambi + Manglik + Bhrigu.

Mangal Dosha = Marte nella casa 1/2/4/7/8/12 dal Lagna, dalla Luna o da Venere (le scuole lo interpretano in modo diverso). In India è un deal-breaker per il matrimonio: se entrambi i partner hanno un’afflizione Mangal senza compensazione, un astrologo tradizionale non dà il via libera senza upaya (rimedi) o fattori compensativi.

Endpoint dell’API: /v1/vedic/compatibility/manglik-check, restituisce { chart1: { manglik: true/false, severity, factors }, chart2: ..., compensation: ... }.

D9 (Navamsha): perché è la varga più importante?

Sezione intitolata “D9 (Navamsha): perché è la varga più importante?”

D9 = divisione di ogni segno in 9 parti = una carta dettagliata “soul-level”. Nel vedico si usa per:

  1. Marriage predictions: Venere + il signore della 7ª nella D9 mostrano la vera natura della vita coniugale
  2. Strength of planets: un pianeta forte nella D1 ma debole nella D9 = “shows but doesn’t deliver”
  3. Vargottama: un pianeta nello stesso segno nella D1 e nella D9 = una forza particolare

API: /v1/vedic/vargas restituisce tutte le 16 divisioni in una sola chiamata; concentrati sulla D9 per le funzioni legate a matrimonio e relazioni.

Perché l’ora di nascita è critica? Cosa fare se non si conosce?

Sezione intitolata “Perché l’ora di nascita è critica? Cosa fare se non si conosce?”

Il vedico è molto sensibile all’ora:

  • Il Lagna (Ascendente) cambia ogni ~2 ore: si sposta TUTTA la carta
  • Il Nakshatra della Luna cambia ogni 6–8 ore
  • Il Dasha-balance (periodo iniziale) dipende dalla nakshatra-position della Luna

Se l’ora esatta non è nota:

  1. Sunrise chart: usa l’ora dell’alba nel luogo di nascita come approssimazione. Il Sole si trova allora sull’Ascendente, quindi il Lagna corrisponde all’incirca al segno solare; alcuni astrologi vedici considerano valide le sunrise chart per una previsione di tendenza generale
  2. Rectification: chiama /v1/rectification con 2-3 eventi di vita noti (matrimonio, figlio, cambio di lavoro): l’API restituisce una finestra probabile per l’ora di nascita
  3. Disclaimer per l’utente: comunica che i risultati con ora sconosciuta sono un’approssimazione, non una carta precisa

Il vedico usa tradizionalmente le case Whole Sign (un intero segno = una casa). L’occidentale Placidus / Koch / Equal ecc.

Il default di AstroWay per il vedico = Whole Sign. Per gli endpoint KP, Placidus (convenzione KP). Passa il parametro houseSystem se ti serve altro: whole-sign, placidus, koch, equal, porphyry.

Si possono combinare vedico e occidentale nella stessa app?

Sezione intitolata “Si possono combinare vedico e occidentale nella stessa app?”

Sì, ed è persino consigliato per un pubblico multi-tradizione. Architettura:

  1. La carta natale si calcola una volta: gli endpoint occidentali e vedici condividono lo stesso input (date/time/lat/lon)
  2. Mostra un toggle “Western view” / “Vedic view” nella tua UI
  3. Il segno lunare vedico (rashi) viene spesso confuso con il segno solare occidentale: avvisa l’utente della differenza
  4. Compatibilità: puoi mostrarle ENTRAMBE, la sinastria occidentale + l’Ashtakoot vedico insieme

L’endpoint /v1/compat/astro-vedic lo fa automaticamente: un ponte tra sinastria occidentale × Ashtakoot vedico.

Swiss Ephemeris (LGPL), le stesse di Solar Fire, Kepler, Astro Gold, Janus, AstroSeek. Precisione:

  • Posizioni planetarie: ±1 secondo d’arco rispetto alle effemeridi NASA JPL
  • Cuspidi delle case: ±1 minuto d’arco
  • Ayanamsa: tabella Lahiri validata in modo incrociato con le tabelle ufficiali del governo indiano

Per i calcoli specificamente vedici (Nakshatra-position, Vimshottari balance, Vargas) c’è una verifica incrociata con PyJHora (il riferimento Python de facto); le divergenze, dove ci sono, sono < 0.01°. Il report sulle divergenze è in docs/AUDIT-TRAIL.md del repo.

Sì: la maggior parte degli endpoint vedici è deterministica per lo stesso chart-input. Una cache key stabile: hash(date + time + lat + lon + ayanamsa + endpoint).

L’API offre anche l’header X-Idempotency-Key: una cache di 5 minuti lato api-calc. Su un cache hit i crediti non vengono addebitati.

Gli endpoint vedici che restituiscono interpretazioni (yoga descriptions, dosha meanings, muhurat reasons) accettano il parametro lang. Supporto: 20 lingue (T0: uk/en/de/ru manuale; T1: pl/es/pt/hi/fr/ko AI Beta; T2/T3: pianificate). Dettagli: /languages/.

Se l’endpoint restituisce dati numerici (degrees, dates, sign indices), sono neutri rispetto alla lingua. I campi di testo (note, meaning, manifestation) sono localizzati.

YELLOW = l’endpoint funziona, ma ha una di tre caratteristiche:

  1. Single-author school (Lal Kitab, KP): non c’è verifica incrociata con altre scuole, perché non esistono
  2. Scoring/heuristic-based (compatibility 0-100, breakup-timing): una valutazione numerica è soggettiva per natura
  3. Intrinsic precision limit (rectification, Bhrigu match): l’algoritmo ha un limite di precisione intrinseco

Consulta docs/AUDIT-TRAIL.md per l’endpoint specifico: lì è scritto perché è YELLOW e se esiste una strada verso GREEN. Per la maggior parte no (è intrinseco), ed è un disclaimer onesto per l’integratore.

Utile?
Suggerisci modifica

Ultimo aggiornamento: