Pular para o conteúdo
AstroWay/api v2.254.12 · pt
todos os sistemas normais

Vedic FAQ

Reunimos as perguntas que surgem com frequência ao integrar os endpoints védicos. Se não encontrares a resposta, escreve para hello@astroway.info e acrescentamo-la.

A API suporta 9 ayanamsas:

CódigoNomeQuando escolher
lahiri (default)Chitra PakshaO padrão do governo da Índia; o maior mercado de massas. Para a maioria das apps védicas, é esta.
ramanB.V. RamanSe estás a integrar uma app móvel para o mercado do Sul da Índia (Karnataka, Tamil Nadu).
krishnamurti (alias kp)KPSe chamas /v1/vedic/kp/*: o KP tem a sua própria ayanamsa.
yukteshwarSri YukteshwarDistância à Spica; públicos teosóficos ou de inclinação ocidental.
fagan-bradleyFagan/BradleySideral ocidental (não védico). Para astrólogos que vêm das tradições siderais ocidentais.
de-luceDe LuceEscolha de astrólogos mais antiga, rara.
jn-bhasinJN BhasinEscola específica, rara.
true-citraTrue Chitra PakshaA Spica fixa a 0° de Balança. Difere do Lahiri em 0.01°, por isso usa-a só se precisares mesmo da ancoragem estelar.
djwhal-khulDjwhal KhulEscola teosófica, rara. O maior desvio da tabela.

As escolas principais divergem pouco: Lahiri, True Chitra e KP ficam dentro de 0.1°, Fagan/Bradley, JN Bhasin, Yukteshwar e Raman até 1.45°. À parte estão De Luce (3.96° do Lahiri) e Djwhal Khul (3.82°), e com elas uma posição perto do limite de um signo já passa para o signo vizinho. Medido a 2026-08-18 com a Lua de um mapa; nas técnicas baseadas em graus (Nakshatra position, Argala) a diferença nota-se mesmo dentro de 0.1°.

Por omissão, os endpoints védicos devolvem posições siderais (zodíaco ancorado nas estrelas, com a ayanamsa aplicada). Os endpoints ocidentais (/v1/chart, /v1/synastry) devolvem posições tropicais (zodíaco ancorado no ponto equinocial).

A API não devolve védico tropical (um edge case raro, proposto por Sanjay Rath e Ernst Wilhelm): todos os endpoints védicos calculam em sideral e ignoram zodiacType no corpo do pedido. As posições tropicais vêm do ramo ocidental (/v1/chart, /v1/synastry), e zodiacType: "sidereal" muda-o para o zodíaco sideral com a mesma ayanamsa.

EscolaRegião / PúblicoPonto forte
Parashara (BPHS)Todo o mundo védico: a base universalO corpus de técnicas mais completo; começa sempre por aqui
JaiminiTamil Nadu + praticantes avançadosPrevisões baseadas em karakas; temas de vida guiados pelo AK
Lal KitabPunjab + Norte da ÍndiaRemédios únicos (upayas), Manglik próprio
KP (Krishnamurti)Tamil Nadu + Andhra PradeshTeoria dos sub-lords, precisão no timing de acontecimentos

Pratyangira, AstroSage e outras APIs grandes dão sobretudo Parashara. A AstroWay cobre as quatro através de grupos de endpoints separados.

AshtakootDashakoota
RegiãoNorte/Centro da Índia, Paquistão, NepalSul da Índia (Tamil Nadu, Karnataka, Kerala)
Escala36 pontos no máximo10 kutas (fatores)
ComponentesVarna + Vashya + Tara + Yoni + Graha Maitri + Gana + Bhakoot + NadiDina + Gana + Mahendra + Stree-Deergha + Yoni + Rasi + Rasyadhipati + Vasya + Rajju + Vedha
API/v1/vedic/compatibility/ashtakoot/v1/vedic/compatibility/dashakoota

Se o teu serviço de matchmaking atende toda a Índia, chama /v1/vedic/compatibility/full: recebes os dois + Manglik + Bhrigu.

Mangal Dosha = Marte na casa 1/2/4/7/8/12 a partir do Lagna, da Lua ou de Vénus (as escolas interpretam de formas diferentes). Na Índia é um deal-breaker para o casamento: se os dois parceiros têm aflição de Mangal sem compensação, o astrólogo tradicional não dá luz verde sem upayas (remédios) ou fatores compensatórios.

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

D9 = divisão de cada signo em 9 partes = um mapa detalhado ao “nível da alma”. No védico usa-se para:

  1. Previsões sobre o casamento: Vénus + o senhor da 7.ª no D9 mostram a verdadeira natureza da vida conjugal
  2. Força dos planetas: um planeta forte no D1 mas fraco no D9 = “promete mas não cumpre”
  3. Vargottama: um planeta no mesmo signo no D1 e no D9 = força especial

API: /v1/vedic/vargas devolve as 16 divisões numa só chamada; concentra-te no D9 para funcionalidades de casamento e relações.

Porque é crítica a hora de nascimento? E se for desconhecida?

Seção intitulada “Porque é crítica a hora de nascimento? E se for desconhecida?”

O védico é muito sensível à hora:

  • O Lagna (Ascendente) muda a cada ~2 horas: e com ele desloca-se TODO o mapa
  • O Nakshatra da Lua muda a cada 6–8 horas
  • O balanço da dasha (período inicial) depende da posição da Lua no nakshatra

Se a hora exata for desconhecida:

  1. Sunrise chart: usa a hora do nascer do Sol no local de nascimento como aproximação. O Sol fica então sobre o Ascendente, pelo que o Lagna coincide aproximadamente com o signo solar; alguns astrólogos védicos consideram os sunrise charts válidos para previsões de tendência geral
  2. Retificação: chama /v1/rectification com 2-3 acontecimentos de vida conhecidos (casamento, filho, mudança de emprego); a API devolve uma janela provável da hora de nascimento
  3. Aviso ao utilizador: diz-lhe que os resultados com hora desconhecida são uma aproximação, não um mapa exato

O védico usa tradicionalmente casas Whole Sign (o signo inteiro = uma casa). O ocidental usa Placidus / Koch / Equal, etc.

O padrão da AstroWay para o védico = Whole Sign. Para os endpoints KP, Placidus (convenção do KP). Passa o parâmetro houseSystem se precisares de outro: whole-sign, placidus, koch, equal, porphyry.

Sim, e é até recomendado para públicos multi-tradição. Arquitetura:

  1. O mapa natal é calculado uma vez: os endpoints ocidentais e védicos partilham a mesma entrada (date/time/lat/lon)
  2. Mostra um toggle “Western view” / “Vedic view” na tua UI
  3. O signo lunar védico (rashi) confunde-se muitas vezes com o signo solar ocidental: avisa o utilizador da diferença
  4. Compatibilidade: podes mostrar OS DOIS ao mesmo tempo, a sinastria ocidental + o Ashtakoot védico

O endpoint /v1/compat/astro-vedic faz isto automaticamente: uma ponte entre a sinastria ocidental e o Ashtakoot védico.

Swiss Ephemeris (LGPL), a mesma do Solar Fire, Kepler, Astro Gold, Janus e AstroSeek. Precisão:

  • Posições planetárias: ±1 segundo de arco face às efemérides JPL da NASA
  • Cúspides das casas: ±1 minuto de arco
  • Ayanamsa: tabela Lahiri validada de forma cruzada com as tabelas oficiais do governo indiano

Os cálculos específicos do védico (Nakshatra-position, Vimshottari balance, Vargas) são verificados de forma cruzada com o PyJHora (a referência de facto em Python); as divergências, onde existem, são < 0.01°. O relatório de divergências está em docs/AUDIT-TRAIL.md no repositório.

Sim: a maioria dos endpoints védicos é determinística para o mesmo chart-input. Chave de cache estável: hash(date + time + lat + lon + ayanamsa + endpoint).

A API oferece também o header X-Idempotency-Key: uma cache de 5 minutos do lado do api-calc. Num cache hit, os créditos não são descontados.

Os endpoints védicos que devolvem interpretações (descrições de yogas, significados de doshas, razões de muhurat) aceitam o parâmetro lang. Suporte: 20 idiomas (T0: uk/en/de/ru manual; T1: pl/es/pt/hi/fr/ko AI Beta; T2/T3: planeados). Detalhes: /languages/.

Se o endpoint devolve dados numéricos (graus, datas, índices de signos), estes são neutros em termos de idioma. Os campos de texto (note, meaning, manifestation) são localizados.

YELLOW = o endpoint funciona, mas tem uma de três características:

  1. Escola de um só autor (Lal Kitab, KP): não há verificação cruzada com outras escolas, porque não existem
  2. Baseado em pontuação ou heurística (compatibility 0-100, breakup-timing): a avaliação numérica é subjetiva por natureza
  3. Limite intrínseco de precisão (rectification, Bhrigu match): o algoritmo tem um piso de precisão inerente

Consulta docs/AUDIT-TRAIL.md para o endpoint concreto: lá está escrito porque é YELLOW e se há caminho para GREEN. Na maioria dos casos não há (é intrínseco), e isso é um aviso honesto para o integrador.

Útil?
Sugerir edição

Última atualização: