Changelog

Mudda dasha

O Mudda dasha agora tem a grafia correta e fica em /api/astro/mudda-dasha/, ao lado do Muntha, na seção Tajika e varshaphala. O antigo /api/astro/muddha_dasha/ foi descontinuado. O novo endpoint devolve os regentes pelo nome e cada início como timestamp ISO, em vez de números de planetas e uma string de data com um dicionário de graus dentro.

• POST /api/astro/mudda-dasha/

O que substitui o quê

Aspectos tajika: use /api/astro/tajika/aspects/ em vez de /api/astro/tajaka/. Yogas tajika: /api/astro/tajika/yogas/ em vez de /api/astro/tajaka_yoga/. Sahams: /api/astro/sahams/ em vez de /api/astro/saham/. Prashnavali: os quatro endpoints /api/astro/prashnavali/ em vez de /api/astro/chakra/. Gun milan: /api/astro/ashtakoota/ com a chave `compatibility_score`, que devolve os mesmos treze valores (as oito pontuações de koota, o total de 36 e as quatro verificações do sul da Índia), em vez de /api/astro/gun-milan/. Shadbala: /api/astro/strength/ em vez de /api/astro/shadbala/. Dashas de nakshatra e de rashi: /api/astro/dasha/nakshatra/ e /api/astro/dasha/rashi/ em vez de /api/nakshatra_dasha/ e /api/raasi_dasha/. Eclipses: os sete endpoints nomeados de /api/astro/eclipse/ em vez do /api/astro/eclipse/ bruto. KP: /api/astro/kp-chart/ em vez de /api/astro/krishnamurti/.

Se você chamar um endpoint descontinuado

Qualquer chamada a um deles com chave de API agora retorna 403 endpoint_not_allowed e não gasta crédito. Troque pelo substituto indicado acima; o SDK e a coleção do Postman já usam os novos.

• POST /api/astro/muddha_dasha/
• POST /api/astro/tajaka/
• POST /api/astro/tajaka_yoga/
• POST /api/astro/saham/
• POST /api/astro/chakra/
• POST /api/astro/gun-milan/
• POST /api/astro/shadbala/
• POST /api/nakshatra_dasha/
• POST /api/raasi_dasha/
• POST /api/astro/eclipse/
• POST /api/astro/krishnamurti/

O que mudou

A lista de celebridades e a consulta de uma celebridade específica não são mais oferecidas. Uma chamada a qualquer um dos dois com chave de API retorna 403 endpoint_not_allowed e não gasta crédito. Todos os outros endpoints continuam iguais. Se você guardou dados de nascimento vindos desses endpoints, ainda pode enviá-los aos endpoints de mapa, como quaisquer outros dados de nascimento.

• GET /api/astro-data/celebrities/
• GET /api/astro-data/celebrities/{id}/

Jamakkol Prashna

Envie a hora local do relógio no momento da pergunta, com o local e o offset UTC. Você recebe os oito jama grahas, Udhayam, Arudam e Kavippu, o jamam do dia ou da noite, Kuligan, Emakandam, Mrithyu e Rahu Time, os planetas e o panchanga do momento. Passe arudam_sign quando o consulente escolher o signo; sem ele, o Arudam é tirado do relógio. Conferido com o jamakkol.com em mais de 20 mapas; para bater exatamente com esse site, envie ayanamsa true_citra com o nodo médio.

• POST /api/astro/prashna/jamakkol/

Ashtamangala Prashna

Envie o momento e o local, o signo Arudha escolhido pelo consulente e os búzios — em três montes ou como o número de três dígitos. Você recebe o Arudha, o Chatra, os seis rasis do Prasna Kriya com o órgão que cada um rege, os cinco Sutras, os planetas contados a partir do Lagna e do Arudha e a leitura completa do número, dígito por dígito. Os sphutas não se repetem aqui: para obtê-los, chame /api/astro/prashna/ com o mesmo momento.

• POST /api/astro/prashna/ashtamangala/

O que mudou

Todos esses endpoints compartilham o serializador de requisição com /api/astro/panchanga/, o único endpoint que de fato calcula as mais de cinquenta chaves de Panchang e precisa de todas as entradas configuráveis que essas chaves usam. Os endpoints específicos herdaram essa lista inteira de campos mesmo assim. Por isso /day-night-length/, que é pura aritmética de nascer e pôr do sol, documentava e aceitava gulika_rises_at, gulika_portion, mandi_rises_at, mandi_portion, kala_mrityu_rise_at e dhuma_vyatipata_relation (configurações de pontos sombra), samvata_type e mode (seletores de era e de contagem), e mean_anomaly, eccentricity, eccentric_anomaly, tolerance e nakshatras — treze campos que o cálculo dele nunca lê. Agora cada endpoint documenta e aceita só os campos que o próprio cálculo usa: /samvat/ mantém samvata_type, /lunar-month/ mantém mode, /upagraha/ mantém os seis campos de gulika/mandi/kala-mrityu/dhuma-vyatipata, e os outros 26 não mantêm nenhum dos treze.

• POST /api/astro/panchang/
• POST /api/astro/rahu-kaal/
• POST /api/astro/choghadiya/
• POST /api/astro/hora/
• POST /api/astro/auspicious-timings/
• POST /api/astro/inauspicious-timings/
• POST /api/astro/vasa-segments/
• POST /api/astro/lunar-phase/
• POST /api/astro/day-night-length/
• POST /api/astro/sankranti/
• POST /api/astro/tithi/
• POST /api/astro/nakshatra/
• POST /api/astro/nitya-yoga/
• POST /api/astro/karana/
• POST /api/astro/abhijit-muhurat/
• POST /api/astro/brahma-muhurat/
• POST /api/astro/amrit-kaal/
• POST /api/astro/durmuhurat/
• POST /api/astro/disha-shool/
• POST /api/astro/muhurta-table/
• POST /api/astro/sandhya/
• POST /api/astro/panchak/
• POST /api/astro/samvat/
• POST /api/astro/lunar-month/
• POST /api/astro/tarabala/
• POST /api/astro/chandrabala/
• POST /api/astro/lagna/
• POST /api/astro/bhava-cusps/
• POST /api/astro/upagraha/

Por que isso importa

Um campo na página de referência de um endpoint promete que configurá-lo faz alguma diferença. Esses não faziam: enviar gulika_rises_at para /day-night-length/ sempre foi ignorado em silêncio, o que é pior do que o campo não existir — convida alguém a perder tempo ajustando algo que nunca muda a resposta. Agora a página de cada endpoint lista exatamente os parâmetros que afetam a saída daquele endpoint, e nada mais.

Nada quebra

O cálculo desses endpoints nunca leu esses campos, então tirá-los da documentação e do schema não muda o comportamento de nenhum endpoint. Se a sua integração já envia um deles para, digamos, /day-night-length/, a requisição continua funcionando e a resposta não muda — conferimos isso com chamadas idênticas antes e depois em todos os endpoints afetados, antes do lançamento. A única diferença é que a página de referência e os tipos gerados do SDK não oferecem mais uma configuração que nunca fez nada.

O que mudou

Catorze blocos: Panchang, Rahu Kaal, Choghadiya, Abhijit e Brahma Muhurat, Durmuhurat, datas de Ekadashi/Amavasya/Purnima/Pradosh/Sankashti Chaturthi, um Calendário de festivais, Rashifal e um formulário de Kundli. Cada um é um bloco de verdade do editor de blocos, arrastado do inseridor como qualquer bloco padrão, com o shortcode correspondente para quem ainda usa o Classic Editor.

Por que isso importa

Quem cuida de um site e nunca escreveu uma linha de PHP consegue colocar um widget de Panchang ao vivo no site no tempo de arrastar um bloco e colar uma chave de API. O plugin é só uma camada fina de exibição sobre os mesmos endpoints que este changelog cobre em outras entradas — sem lógica de cálculo própria, então nunca diverge da API.

Os dezesseis shodasavarga agora têm rota — 8 novos

D1 rashi, D4 chaturthamsa, D16 shodasamsa, D20 vimsamsa, D24 chaturvimsamsa, D27 nakshatramsa, D40 khavedamsa e D45 akshavedamsa se juntam aos oito já publicados (D2, D3, D7, D9, D10, D12, D30, D60). NADA DE NOVO É CALCULADO — /api/astro/chart/ sempre gerou esses mapas via chart_name, e as novas rotas delegam para a mesma view, então os números são idênticos por construção. O que muda é que agora dá para encontrá-los: uma rota chamada /navamsa/ aparece numa busca; um chart_name enterrado no corpo da requisição, não. /api/astro/rashi/ é a mesma view com o mapa fixo e devolve uma saída idêntica, byte a byte, à de /api/astro/planet-positions/ — um teste garante exatamente isso, então os dois não podem divergir.

• POST /api/astro/rashi/
• POST /api/astro/chaturthamsa/
• POST /api/astro/shodasamsa/
• POST /api/astro/vimsamsa/
• POST /api/astro/chaturvimsamsa/
• POST /api/astro/nakshatramsa/
• POST /api/astro/khavedamsa/
• POST /api/astro/akshavedamsa/

Quatro divisões fora do shodasavarga — 4 novos

D5 panchamsa (fama e autoridade), D6 shashthamsa (saúde e inimigos), D8 ashtamsa (longevidade e acontecimentos súbitos) e D11 rudramsa (ganhos). Esses mapas são usados junto com os dezesseis clássicos, sem fazer parte deles, e cada resposta diz isso. VALE SABER sobre o D11: duas tradições o leem em sentidos opostos — uma como ganhos, como sugere a casa 11; a outra como Rudra e, portanto, destruição. Não escolhemos por você.

• POST /api/astro/panchamsa/
• POST /api/astro/shashthamsa/
• POST /api/astro/ashtamsa/
• POST /api/astro/rudramsa/

Além do D60 — 3 novos

D81 navnavamsa, D108 astottaramsa e D144 dwadasdwadasamsa. SÃO DIVISÕES COMPOSTAS, e o motor tem duas leituras de cada uma: a divisão direta do rashi em 81, 108 ou 144 partes, e o varga de um varga. Estas rotas servem a leitura COMPOSTA, porque é o que cada nome diz ao pé da letra — nava-navamsa é o navamsa do navamsa; dwadas-dwadasamsa, o dwadasamsa do dwadasamsa. A divisão direta continua disponível em /api/astro/chart/ como NavnavamsaChart, AstottaramsaChart e DwadasdwadasamsaChart, e dá outro signo para a maioria dos planetas — são mapas diferentes, não duas grafias do mesmo. Um teste garante que os dois de fato diferem, para a escolha não ser invertida por acidente. Com 22, 17 e 12 minutos de arco por divisão, esses mapas só valem a leitura quando a hora de nascimento é conhecida de verdade, ao minuto; abaixo disso, o que eles mostram é o arredondamento da sua certidão de nascimento.

• POST /api/astro/navnavamsa/
• POST /api/astro/astottaramsa/
• POST /api/astro/dwadasdwadasamsa/

A documentação agora lista os mapas na ordem das divisões

A referência ordenava cada grupo alfabeticamente, o que punha D10 antes de D2 e D144 antes de D16 — uma bagunça que fazia a série parecer incompleta mesmo quando não estava, porque quem procurava o D20 não sabia onde olhar. Agora os mapas divisionais aparecem ordenados pelo número da divisão em todo lugar.

Nada do que já existia mudou

As quinze são rotas novas que fixam um chart_name e, no resto, delegam para a view que já atende /api/astro/planet-positions/. /api/astro/chart/ continua aceitando todos os chart_name de antes, inclusive os cômputos alternativos sem rota própria — ParivrittidwayaHora, SomnathDrekkana, JagannathDrekkana e os demais. Esses ficam onde estão: são variantes de uma divisão que já tem rota, procuradas por quem já sabe o nome que quer.

Rashifal por período e área da vida — 6 novos

/api/astro/rashifal/ devolve uma amostra rotativa de 3–4 áreas, e quais entram muda com a data — por isso uma página de “Saúde de Áries” não podia existir: em alguns dias, health não estava na amostra. Estes seis devolvem TODAS as áreas em toda chamada: general, career_business, love_relationships, money_finances, health, education_student, family, travel e duas que o motor base nunca teve, business e professionals. Passe aspect para receber só uma, que é o formato de que uma página por área precisa. As leituras são determinísticas — o mesmo signo, período, área e data sempre devolvem as mesmas palavras, então a página pode ficar em cache e não se contradiz ao recarregar. O semanal acrescenta os melhores dias e os mais difíceis; o mensal, trânsitos, dias especiais e remédios; o anual, uma previsão por trimestre e elementos de sorte. rashi e aspect não diferenciam maiúsculas de minúsculas, como no endpoint que já existia.

• POST /api/astro/rashifal/daily/
• POST /api/astro/rashifal/tomorrow/
• POST /api/astro/rashifal/yesterday/
• POST /api/astro/rashifal/weekly/
• POST /api/astro/rashifal/monthly/
• POST /api/astro/rashifal/yearly/

Nove sistemas de numerologia — 10 novos

A Cabala mapeia um nome nos 22 caminhos da Árvore, cada um com sua letra hebraica e seu arcano maior do tarô. A gematria pontua texto hebraico em cinco cifras (standard, gadol, ordinal, katan, atbash). O tarô dá as cartas de nascimento, de parceiro e do nome; o I Ching, os hexagramas de nascimento e do nome na sequência King Wen de 64; Sepharial, a própria tabela de 1920, com seus regentes planetários; Cheiro, a tabela caldeia reduzida a um número composto. Abjad e isopsefia pontuam árabe e grego, incluindo as letras numerais obsoletas — digamma, koppa, sampi. TRÊS DESSES SISTEMAS DEPENDEM DO ALFABETO: abjad é árabe, isopsefia é grega e gematria é hebraica. Se receberem o alfabeto errado, devolvem o valor 0 e listam cada caractere em unscored, em vez de transliterar — cada fonte translitera de um jeito, e um número convicto saído de uma escolha arbitrária é pior que um zero óbvio.

• POST /api/astro/numerology/kabbalah/
• POST /api/astro/numerology/gematria/
• POST /api/astro/numerology/tarot/
• POST /api/astro/numerology/iching/
• POST /api/astro/numerology/sepharial/
• POST /api/astro/numerology/abjad/
• POST /api/astro/numerology/isopsephy/
• POST /api/astro/numerology/angel/
• POST /api/astro/numerology/aura/
• POST /api/astro/numerology/cheiro/

Casas, planetas e layout do mapa de Lal Kitab — 3 novos

A mesma tradição de casas fixas das duas rotas lançadas ontem, nos três formatos de que uma página realmente precisa para renderizar. /horoscope/ é o mapa em doze casas de signo, com o grau de cada ocupante dentro do signo. /houses/ dá a cada casa o seu regente, os grahas que têm ali o seu pakka ghar e quem está exaltado ou debilitado ali — pakka_ghar é uma LISTA, porque Mercúrio e Vênus dividem a 7ª, Marte e Saturno a 8ª, e Júpiter e Rahu a 12ª, e um valor único deixaria um deles de fora. /planets/ dá a cada graha sua dignidade e natureza. A natureza da Lua e a de Mercúrio são calculadas, não fixas — a da Lua pelo paksha, a de Mercúrio conforme um maléfico natural divida ou não o signo com ele —, e cada linha traz nature_basis, dizendo qual regra decidiu. VALE SABER: position é null para Rahu e Ketu, a não ser que estejam exaltados ou debilitados. Eles não regem nenhum signo, então “signo de um amigo” não tem referência para comparar.

• POST /api/astro/lal-kitab/horoscope/
• POST /api/astro/lal-kitab/houses/
• POST /api/astro/lal-kitab/planets/

O que continuamos sem responder

As dívidas do Lal Kitab (rin) e o dasha do Lal Kitab ficaram de fora de propósito, assim como os campos soya e kismat que outros fornecedores devolvem no endpoint de casas. Os nomes das oito dívidas são consenso entre as fontes; as condições que ativam cada uma, não — só as regras publicadas para o pitra rin já divergem a ponto de dar respostas diferentes para o mesmo mapa. O mesmo vale para soya. Preferimos não devolver nada a publicar um veredito sobre os antepassados de alguém no cara ou coroa, então esses campos ficam de fora e a resposta explica por quê.

Nada do que já existia mudou

As dezenove são rotas novas. /api/astro/rashifal/ continua recebendo o mesmo corpo e devolvendo a mesma amostra rotativa. Os nove novos sistemas de numerologia formam um módulo próprio, e não valores novos em /api/astro/numerology/, então os campos system e keys de lá continuam intactos. Cheiro reaproveita a tabela de letras caldeia e os significados compostos que a API já tinha, em vez de repeti-los.

Relatórios em PDF prontos — 2 novos

O corpo da resposta É o PDF. Não há segunda requisição nem arquivo hospedado: não guardamos nada, então não existe link para outra pessoa encontrar. Não chame .json() nesses endpoints — grave os bytes em disco (curl -o report.pdf, res.arrayBuffer(), response.content). O horóscopo tem cerca de 27 páginas, com sumário gerado automaticamente; o anuário divide os próximos doze meses por pratyantardasha de Vimshottari, e não por mês do calendário, então suas seções começam e terminam em datas que o seu mapa define. Os dois aceitam um bloco branding opcional — nome da empresa, contatos e um logo_url que buscamos e colocamos na capa —, para o seu cliente ver o seu nome, e não o nosso. Os dois são determinísticos: os mesmos dados de nascimento geram o mesmo documento. O tempo típico fica abaixo de dois segundos.

• POST /api/astro/pdf/horoscope/ · 25 créditos
• POST /api/astro/pdf/yearbook/ · 25 créditos

Kala Sarpa e Karakamsa — 2 novos

O Kala Sarpa devolve quais grahas caíram de cada lado do eixo Rahu–Ketu, e não só um sim ou não — a maioria dos mapas não é Kala Sarpa, e as duas listas mostram se faltou um graha ou quatro. A forma nomeada (Anant, Kulik, Vasuki …) só é preenchida quando o yoga de fato se forma. VALE SABER: /api/astro/karakamsa/ ordena os chara karakas pelo grau DENTRO do signo e, na maioria dos mapas, aponta um Atmakaraka diferente do de /api/astro/chara-karakas/. Os dois são calculados de formas diferentes e não são intercambiáveis; para trabalhar com karakamsa, prefira o novo.

• POST /api/astro/kalsarp/
• POST /api/astro/karakamsa/

Chakra Sarvatobhadra — 1 novo

O tabuleiro de trânsitos de nove por nove, com a grade inteira devolvida junto com as posições — para você poder desenhá-lo, e não só ler um veredito. Cada célula diz o que contém, o sombreamento e as quatro sílabas de pada do seu nakshatra. Passe transit_date_time para colocar os grahas em trânsito no mesmo tabuleiro; hits_natal então lista aqueles cujo vedha cai num nakshatra ocupado no seu mapa natal. Só o vedha posicional é aplicado, e rule diz isso em toda resposta, porque as escolas divergem e uma resposta sem identificação não pode ser conferida. Uma grafia de nakshatra que não conseguimos identificar volta em unplaced, em vez de ser descartada.

• POST /api/astro/sarvatobhadra/

Lal Kitab — 2 novos

Uma tradição à parte, do norte da Índia, e a primeira coisa a saber é que NO LAL KITAB AS CASAS SÃO FIXAS NOS SIGNOS — a casa 1 é sempre Áries, e assim por diante até a casa 12, sempre Peixes, em qualquer mapa. A casa de um planeta é o número do seu signo, então estes endpoints VÃO divergir de /api/astro/chart/ e /api/astro/planet-positions/ para quase todo mundo. Esse é o sistema, não um erro. Cada graha vem com o seu pakka ghar e se está nele ou não. O varshphal é aritmético, não astronômico: cada planeta avança uma casa por ano completo de idade, então o mapa anual volta à disposição natal a cada doze anos.

• POST /api/astro/lal-kitab/chart/
• POST /api/astro/lal-kitab/varshphal/

O Playground agora entrega o arquivo

Ao rodar um endpoint que responde com um arquivo, o Playground agora mostra o nome, o tipo e o tamanho dele, com um botão Download, em vez de tentar exibir os bytes como texto. A página de referência desses endpoints também parou de mandar descompactar e fazer parse — esse texto era das rotas de JSON com gzip e estava errado para um PDF.

Nada do que já existia mudou

Os cinco endpoints de cálculo são rotas novas que delegam para as views que já atendem /api/astro/planet-positions/ e os mapas divisionais, então os números são idênticos por construção. Os relatórios em PDF são montados chamando esses mesmos endpoints internamente — as posições impressas na página 3 são exatamente as que /api/astro/planet-positions/ devolve —, e o relatório inteiro é cobrado como uma chamada, não como as vinte e cinco que o compõem.

Dashas de nakshatra condicionais — 7 novos

Baseados em planetas: todo regente na resposta é um graha. Os sete são CONDICIONAIS — os textos clássicos só os aplicam quando o mapa cumpre uma condição específica, então consulte /api/astro/dasha_applicability/ antes de oferecer um deles numa leitura.

• POST /api/astro/dasha/dwadashottari/
• POST /api/astro/dasha/panchottari/
• POST /api/astro/dasha/sataabdika/
• POST /api/astro/dasha/chaturaseeti-sama/
• POST /api/astro/dasha/dwisaptati/
• POST /api/astro/dasha/shattrimsa-sama/
• POST /api/astro/dasha/budhi-gati/

Dashas de rashi de Jaimini — 15 novos

Baseados em signos: aqui todo regente é um rashi, não um planeta. É essa a diferença para ficar de olho — o campo lord indica outro tipo de coisa do que nos dashas de nakshatra acima, e ler o errado gera uma saída impossível de interpretar.

• POST /api/astro/dasha/drig/
• POST /api/astro/dasha/nirayana-shoola/
• POST /api/astro/dasha/shoola/
• POST /api/astro/dasha/sthira/
• POST /api/astro/dasha/trikona/
• POST /api/astro/dasha/brahma/
• POST /api/astro/dasha/chakra/
• POST /api/astro/dasha/kendradhi/
• POST /api/astro/dasha/lagnamsaka/
• POST /api/astro/dasha/mandooka/
• POST /api/astro/dasha/navamsa/
• POST /api/astro/dasha/paryaaya/
• POST /api/astro/dasha/sandhya/
• POST /api/astro/dasha/tara-lagna/
• POST /api/astro/dasha/yogardha/

Um ramo, em vez da árvore inteira — 1 novo

levels limita a PROFUNDIDADE de uma resposta de dasha, mas ainda devolve todos os períodos naquela profundidade: levels=3 no Vimshottari traz cada pratyantardasha de cada antardasha de cada mahadasha — 95 KB, medidos. Envie {"lords": ["moon", "mars"], "levels": 1} e você recebe só os períodos dentro daquele antardasha, cerca de 1,8 KB. Isso economiza transferência e parsing, não processamento.

• POST /api/astro/dasha/drill/

Chat de astrologia — 1 novo

Envie os dados de nascimento e uma pergunta e receba uma resposta em texto corrido — com as passagens clássicas em que ela se baseou, cada uma citada e pontuada, para o raciocínio poder ser conferido. Os dados de nascimento vêm da SUA requisição, e não de uma conta, então você pode perguntar em nome de qualquer usuário seu. Adicione compare_with para perguntas de compatibilidade e passe até vinte turnos anteriores em history. Nada fica guardado entre as chamadas. Custa 25 créditos em vez de 1, porque cada resposta roda um modelo de linguagem sobre o mapa calculado; uma resposta que falha ou vem vazia não custa nada.

• POST /api/astro/chat/ · 25 créditos

Trinta sistemas de dasha, agora agrupados por família

Com estes, trinta sistemas têm endpoint com nome — antes eram oito. Os demais só eram acessíveis passando uma string para /api/nakshatra_dasha/ ou /api/raasi_dasha/, então buscar “narayana dasha” não dava em nada. Na referência, eles agora ficam em três grupos — nakshatra (planetárias), rashi (Jaimini) e ferramentas —, em vez de uma única lista alfabética de trinta e cinco que punha o Brahma dasha ao lado do Budhi Gati dasha.

Nada do que já existia mudou

/api/nakshatra_dasha/ e /api/raasi_dasha/ continuam intactos, e os oito endpoints de dasha que já existiam se comportam exatamente como antes — cada rota nova delega para a mesma view de origem, então os números são idênticos por construção, e não por uma cópia que poderia divergir. O endpoint de chat é separado das rotas /api/ai/ que o app já tinha, e elas não mudaram.

O que há de novo

POST /api/astro/prashnavali/ram-shalaka/ devolve os 225 chaupais do Ram Shalaka Prashnavali, cada um com sua letra em devanágari, o chaupai, o trecho do Ramcharitmanas onde aparece e uma resposta em inglês. /api/astro/prashnavali/hanuman/ devolve as 49 respostas numeradas; /api/astro/prashnavali/sai/, as 720 respostas de Sai; e /api/astro/prashnavali/mavji/, as 64 leituras de Mavji Maharaj em hindi e inglês. Na referência, os quatro ficam juntos na nova categoria Avatar chakra.

Três coisas que eles fazem e o endpoint original não

O filtro é opcional em todos. /api/astro/chakra/ recusa uma requisição de sai_prashnavali sem número; estes endpoints devolvem o conjunto inteiro, que é como dados de oráculo costumam ser usados — buscar uma vez, guardar em cache, indexar localmente. As entradas voltam como LISTA, com o índice em cada entrada, e não como um objeto com números convertidos em string como chaves. Assim, dá para percorrer em ordem sem ordenar numericamente chaves de texto (que, sem isso, ficam 1, 10, 100, 11). E toda resposta traz count, então uma consulta de uma entrada só se distingue de uma busca completa sem precisar examinar o payload.

Nada do que já existia mudou

/api/astro/chakra/ continua intacto. Ele ainda serve os quatro conjuntos de dados pelo campo keys, ainda devolve o mesmo formato {key: data} e ainda devolve 400 para sai_prashnavali sem número. Se você já integrou com ele, nada aqui afeta você — são rotas a mais, não um substituto.

Renomeados na referência

“KP (Krishnamurti) chart” e “Krishnamurti paddhati” agora se chamam “Mapa KP (cúspides, signos e planetas)” e “Partes KP (escolha com keys)” — o primeiro entrega o mapa inteiro; o segundo pede que você diga quais partes quer. “House lord placements” e “House lord placement”, que diferiam numa letra, agora terminam em “(todos os 144)” e “(um par)”. Dois endpoints chamados “Pancha Pakshi” agora são “(atividade das aves por hora)” e “(dia em dez yamas)”. “Birth panchanga effects” e “Birth panchanga readings” agora terminam em “(tabela de referência)” e “(seus elementos)”.

As rotas não mudaram

Esses são só os nomes exibidos na documentação. Todas as rotas, campos de requisição e campos de resposta continuam exatamente iguais — não há nada para atualizar na sua integração. Se você salvou uma página da documentação nos favoritos, a URL continua funcionando; só o título no topo ficou mais claro.

Capturas de tela nas páginas de referência

43 páginas de endpoint agora trazem uma captura de tela com os dados daquele endpoint exibidos numa interface real — panchang, choghadiya, o calendário de festivais, retrogradações, onze calendários regionais, mapas natais e mais. Uma tabela de campos mostra o formato da resposta, mas não para que ela serve, e uma olhada costuma bastar para saber se é o endpoint que você procura. O índice da documentação e a página inicial trazem as mesmas imagens.

O que mudou

/api/astro/chart/ agora aceita um campo render opcional. Sem ele, nada muda — a resposta é exatamente a de sempre. Com "svg", aparecem mais dois campos ao lado dos quatro habituais: layout (os pontos do polígono de cada célula de casa ou signo, a posição do rótulo e quais planetas estão nela) e svg (o markup renderizado, para colocar direto na página). chart_style escolhe o estilo do norte da Índia (o losango, casas fixas, signos que giram) ou do sul (a grade fixa de signos, casas que giram); svg_size, theme, label_style, show_degrees e quatro campos *_color controlam a aparência.

Por que isso importa

Montar a roda de um mapa a partir de longitudes brutas dá trabalho de verdade — geometria das casas, rotação dos signos, posição dos rótulos —, e cada integrador refazia tudo do zero. Agora é um campo numa chamada que você já fazia. A geometria do layout fica disponível para quem renderiza nativamente em React, Canvas, Flutter ou SwiftUI, sem usar o nosso markup.

Nada do que já existia mudou

O padrão de render é "none", e todos os outros campos novos têm um padrão que não faz nada. Uma requisição que não usa nenhum deles recebe uma resposta idêntica, byte a byte, à de antes desta mudança — conferido em todos os tipos de mapa e opções que este endpoint aceita.

Dashas que aparecem na busca

Já calculávamos trinta sistemas de dasha — onze dashas de nakshatra e dezenove de rashi, cada um com vários níveis de aninhamento —, mas eles eram valores de uma string dasha_type em dois endpoints chamados nakshatra_dasha e raasi_dasha. Buscar “vimshottari dasha” não dava em nada. Agora há rotas com nome: /api/astro/dasha/vimshottari/, /yogini/, /ashtottari/, /chara/, /narayana/, /kalachakra/ e outras, além de /api/astro/dasha/systems/, que lista cada sistema com o endpoint que o atende. Os dois endpoints originais continuam intactos e funcionando.

Qual dasha está em curso agora

/api/astro/dasha/current/ responde à pergunta que os endpoints de linha do tempo não respondiam: devolve a cadeia a partir do mahadasha — “Júpiter / Ketu / Mercúrio” —, com o início e o fim de cada nível, quanto dele já passou e quantos dias faltam. Antes, era preciso buscar a árvore inteira, percorrê-la recursivamente e comparar datas no seu próprio código.

Astrologia ocidental tradicional e helenística

/api/astro/traditional/dignities/ devolve domicílio, exaltação, triplicidade, termo e face de cada planeta, com a pontuação de Lilly; /almuten/ dá o planeta com mais dignidade sobre cada ponto do mapa; /sect/ diz se o mapa é diurno ou noturno e o que decorre disso; /profections/ dá as profecções anual, mensal e diária, com o Senhor do Ano. Tudo é tropical, como a doutrina exige, e a resposta informa quais tabelas de termos e triplicidades foram usadas — as fontes divergem, e uma pontuação calculada com outra tabela dá outro número.

Mapas derivados e a Lua

Mapas dracônico, harmônico, de antiscia, heliocêntrico e Davison em /api/astro/western/, além de /api/astro/lunar/void-of-course/ e /api/astro/lunar/mansions/. A Lua fora de curso é uma busca para a frente, não um retrato do momento: varre até a Lua mudar de signo, informa cada aspecto que vai se completar e exatamente quando, e diz quando o período fora de curso começa e termina.

Quatro Pilares chineses

/api/astro/chinese/four-pillars/, /bazi/, /zodiac/ e /luck-pillars/. O ano chinês começa no Lichun, por volta de 4 de fevereiro — não em 1º de janeiro nem no Ano-Novo Chinês, que é uma data lunar e marca a festa, não o mapa. Um nascimento em 20 de janeiro de 2024 dá Coelho de Água, e não Dragão de Madeira. A convenção de virada do dia e a do tempo solar verdadeiro são campos da requisição, porque os praticantes divergem e cada uma muda o mapa.

Tarô

/api/astro/tarot/draw/, /spread/, /yes-no/ e /deck/. Toda tiragem devolve a seed que a gerou, e reenviar essa seed reproduz a tiragem exatamente — mesmas cartas, mesma ordem, mesma orientação. É isso que permite guardar uma leitura e mostrá-la de novo, em vez de dar ao consulente outra resposta para a mesma pergunta. Seis tiragens com nome, até a Cruz Celta de dez cartas, com cada posição identificada.

Também novo

/api/astro/eclipse/visibility-path/ traça onde um eclipse solar é total, em coordenadas que você pode desenhar num mapa, com o ponto de eclipse máximo e a série de Saros. Outros nove endpoints isolam cálculos que antes exigiam saber quais chaves pedir a um endpoint maior: prastara e sodhana do ashtakavarga, aspectos e yogas tajika, coordenadas horizontais e equatoriais dos planetas, iluminação da Lua, segmentos vasa e cazimi.

Nada do que já existia mudou

Todos os endpoints adicionados aqui são rotas novas. Nenhum corpo de requisição, formato de resposta ou nome de campo de endpoints existentes foi alterado, e nenhum endpoint foi removido ou renomeado. O preço não mudou: uma chamada bem-sucedida custa um crédito, seja qual for o retorno.

O que mudou

Endpoints como /api/astro/sunrise/, /api/astro/tithi/, /api/astro/navamsa/ e /api/astro/rahu-kaal/ recebem os campos habituais de nascimento ou de data e devolvem só aquilo que o nome diz. Os endpoints combinados que já existiam não mudaram e continuam funcionando exatamente como antes.

Por que isso importa

Mostrar a hora do nascer do sol não exige mais pedir, pagar e fazer parse de uma resposta completa de panchang. Payloads menores, menos código de mapeamento e um corpo de requisição fácil de ler.

Como começar

Explore a referência e envie a requisição de exemplo com a sua chave no cabeçalho X-API-Key. O preço não mudou: uma chamada bem-sucedida custa um crédito, seja qual for o retorno.

O que mudou

A busca encontra o recurso, e não só o nome do endpoint. Digite “manglik” e ela acha o endpoint de doshas, mesmo sem a palavra “manglik” no nome — e o resultado mostra qual campo bateu.

Por que isso importa

Por trás da lista de endpoints há várias centenas de campos. Sem busca pelos nomes dos campos, achar o que você precisava significava abrir os endpoints um por um e ler as respostas.

O que mudou

O servidor MCP occult-api expõe como ferramentas a busca de endpoints, a descrição de cada endpoint e as chamadas. Configure-o com a sua chave de API, e o assistente consegue achar o endpoint certo e chamá-lo diretamente.

Por que isso importa

É o jeito mais rápido de testar a API com uma pergunta real antes de se comprometer a construir qualquer coisa — e ainda serve de implementação de referência, funcionando, do formato das requisições.

O que mudou

A página de cada endpoint leva direto ao Playground, com a requisição de exemplo já preenchida. Mude a latitude, a data ou o ayanamsa e envie de novo.

Por que isso importa

Ler uma resposta de exemplo mostra o formato dos dados. Enviar os seus próprios dados mostra se ela responde à sua pergunta.

O que mudou

Crie sua conta, gere uma chave e envie-a no cabeçalho X-API-Key. Os créditos são descontados a cada chamada bem-sucedida — requisição que falha nunca é cobrada.

Por que isso importa

Nenhuma tabela de preços por endpoint para decifrar. Os cálculos usam dados de efemérides da NASA JPL, com um conjunto completo de ayanamsas clássicos e modernos.