Extension de la Numérologie + Extension de l'Horoscope v1.0.0 - Chronologie des modifications unifiée¶

Date de sortie: 2026-04-12 Version: v1.0.0 Portée: Publication de la plateforme complète, couvrant The Numerology API, Extension de l'Horoscope: incluant le déploiement des points d'extrémité étendus, la migration des rapports d'horoscope basés sur le moteur, la normalisation des requêtes/réponses, la cohérence de la documentation, la validation multilingue et les directives d'intégration en production.

Aperçu¶

v1.0.0 est une publication de production majeure sur la plateforme Dakidarts API. Elle regroupe deux grands projets en une seule publication coordonnée :

1. Extension de la Numérologie
2. Ajoute la surface complète et étendue de la numérologie.
3. Élargit la couverture du temps/cycle avec la semaine personnelle et le jour/semaine/mois/année universel.
4. Introduit des points d'extrémité plus approfondis pour l'analyse spirituelle, relationnelle, de l'identité et de l'ombre.
5. Complète la cohérence de la documentation, les exemples de réponses et la validation multilingue.2. Extension de l'Horoscope
6. Complète la migration majeure de la génération de rapports d'horoscope vers le moteur Swiss Ephemeris.
7. Standardise les routes de rapports basées sur le moteur sous /api/v1/horoscope/reports/*.
8. Ajoute une couverture étendue des sections pour les périodes quotidiennes, hebdomadaires, mensuelles et annuelles.
9. Introduit des suites de rapports planétaires, d'aspects, de transit et de maisons périodiques.
10. Renforce la cohérence des données, le comportement de personnalisation, les alias de compatibilité et la cohérence de la documentation.

Ce journal de modifications est destiné à servir de source unique de vérité pour les intégrateurs, les revues internes, le support, la planification de la migration et la communication de lancement auprès des clients.

Points forts à l'échelle de la plateforme¶

Ce que v1.0.0 apporte à l'ensemble de la plateforme- Version 1.0.0 de production pour les API Numerology et Horoscope.¶

• Extension importante de la surface des points d'extrémité pour les produits de numérologie et d'horoscope.
• Finalisation de la migration de la computation horoscopique basée sur le moteur pour les principaux flux de rapports.
• Finalisation de la version Numerology étendue.
• Amélioration des modèles de requêtes structurées POST pour les routes horoscopiques mises à niveau.
• Prise en charge plus large des payloads de réponses riches, des wrappers d'entreprise et de la cohérence des métadonnées.
• Parité de documentation accrue entre les documents publics et les payloads d'exemple.
• Validation multilingue réussie pour les points d'extrémité étendus de numérologie.
• Amélioration de la clarté des routes, de la gestion de la compatibilité et des directives de migration pour les clients de production.
• Prise en charge élargie des calculs personnalisés lorsque les vecteurs de naissance et les champs de requête avancés sont fournis.
• Amélioration de la clarté opérationnelle concernant le fuseau horaire, le système astrologique, l'ayanamsa, les systèmes de maisons et le comportement des nœuds dans les flux de requêtes horoscopiques.

Résumé de la composition de la version### Expansion de la API Numerologie¶

• Nouvelles familles d'endpoints ajoutées : 23
• Opérations combinées ajoutées (GET/POST) : 41
• Requêtes de validation/vérification exécutées : 205
• Documentation multilingue réussie : 100,0 %
• Modèle de déploiement étendu : additif, sans déprécations formelles dans la nouvelle suite étendue

Expansion de la API Horoscope¶

• Principaux ensembles de rapports migrés vers le moteur interne
• Nouveaux ensembles de rapports ajoutés pour :
• planétaires
• aspects
• transits
• maisons
• planète-maison
• Espace de noms de rapport canonique établi sous :
• /api/v1/horoscope/reports/*
• Plusieurs routes héritées conservées comme alias de compatibilité cachés pendant que la documentation publique évolue avec les chemins canoniques

Partie I — API Numerologie v1.0.0¶

Points forts de l'expansion de la API Numerologie- Ajouté la documentation complète de la Numérologie étendue dans la section de documentation étendue.¶

• Ajouté et complété Semaine Personnelle avec une parité GET/POST complète et un support pour des payloads de réponse riches.
• Ajouté et complété les Extensions du Cycle Universel:
• Jour Universel
• Semaine Universelle
• Mois Universel
• Année Universelle
• Standardisé la documentation des points d'extrémité étendus avec des tableaux de paramètres complets, des options, des exemples de réponses et des liens vers des points d'extrémité connexes.
• Confirmé la couverture multilingue pour en, es, de, fr, pt à 100 % de succès pour les opérations étendues.
• Clarifié le modèle d'accès : les points d'extrémité étendus sont exclusifs à la plateforme et ne sont pas actuellement pris en charge via le gateway RapidAPI.

Extension de la Numérologie — Nouveaux Points d'extrémité Ajoutés¶

Cette version ajoute 23 familles de points d'extrémité étendus et 41 opérations (GET/POST combinées).

A) Points d'extrémité de Cycles et de Timing| Endpoint | Méthodes | Chemin |¶

|---|---|---| | Semaine Personnelle | GET, POST | /api/v1/personal-week | | Année Universelle | GET, POST | /api/v1/universal-year | | Mois Universel | GET, POST | /api/v1/universal-month | | Semaine Universelle | GET, POST | /api/v1/universal-week | | Jour Universel | GET, POST | /api/v1/universal-day | | Carte Thermique de l'Énergie Mensuelle | GET, POST | /api/v1/monthly-energy-heatmap | | Calendrier des Dates à Prudence | GET, POST | /api/v1/caution-dates-calendar |

B) Points d'extrémité d'identité et d'intelligence des noms¶

C) Points d'extrémité d'analyse spirituelle et de l'ombre| Endpoint | Méthodes | Chemin |¶

|---|---|---| | Lecture de la fréquence de l'Aura | GET, POST | /api/v1/aura-frequency-reading | | Numerologie du Chakra | GET, POST | /api/v1/chakra-numerology | | Modèles de vie passés | GET, POST | /api/v1/past-life-patterns | | Nombre de travail de l'ombre | GET, POST | /api/v1/shadow-work-number | | Lecture du contrat de l'âme | GET, POST | /api/v1/soul-contract-reading | | Indicateur de connexion de l'âme | POST | /api/v1/soul-connection-indicator | | Lecture des dons spirituels | GET, POST | /api/v1/spiritual-gifts-reading | | Lecture de l'équilibre sacré | GET, POST | /api/v1/sacred-balance-reading |

D) Endpoints pour les dynamiques relationnelles¶

API de Numerologie — Endpoints mis à jour et corrigés¶

A) Surfaces de base étendues nouvellement complétées¶

Les surfaces suivantes ont été complétées de bout en bout dans ce cycle de publication, avec validation de requête et sortie de sens riche :

• GET /api/v1/personal-week
• POST /api/v1/personal-week
• GET /api/v1/universal-year
• POST /api/v1/universal-year
• GET /api/v1/universal-month
• POST /api/v1/universal-month
• GET /api/v1/universal-week
• POST /api/v1/universal-week
• GET /api/v1/universal-day
• POST /api/v1/universal-day### B) Corrections de stabilité appliquées lors de la validation initiale

Cinq opérations qui produisaient initialement 422 avec des entrées de fumée générées ont été stabilisées pour une couverture de tests similaire à la production et renvoient désormais des réponses réussies sous des entrées de fumée multilingues :

• POST /api/v1/brand-name-compare
• GET /api/v1/caution-dates-calendar
• POST /api/v1/caution-dates-calendar
• GET /api/v1/monthly-energy-heatmap
• POST /api/v1/monthly-energy-heatmap

C) Règles de validation pratiques renforcées¶

Les règles suivantes ont été renforcées et clarifiées lors du processus de validation et de documentation :

• La comparaison de marques nécessite au moins deux entrées dans names[].- Les entrées de calendrier et de heatmap mois utilisent le format YYYY-MM.- Les dates à prendre en compte top_n restent limitées à la plage 1..31.- Les payloads des clients bénéficient d'une prévalidation avant soumission afin de réduire les erreurs inutiles de type 422 ou les erreurs au niveau du format.

D) Corrections pour la cohérence de la documentation et de l'OpenAPI¶

All extended docs were normalized for integration parity:

• Compléter les tableaux de paramètres pour chaque méthode

--- FIN MARKDOWN ---- détails des options du paramètre

--- FIN MARKDOWN ---- schémas, plages, valeurs par défaut, et champs d'objets imbriqués

---- Exemples de réponses riches basés sur des payloads générés par des tests

---- notes standardisées sur l'accès et la disponibilité

--- FIN MARKDOWN ---- Boutons d'appel à l'action (CTA) du tableau de bord, sections de notes et pieds de page des points de terminaison associés

---¶

Numerology API — Vérification QA¶

Artefacts de validation pour la suite de numerologie étendue :

• Fichiers de résumé : 23
• Opérations testées : 41
• Nombre total de requêtes exécutées : 205
• Taux de réussite global : 100,0 %
• Taux de réussite par langue :
• en — 100 %
• es — 100 %
• de — 100 %
• fr — 100 %
• pt — 100 %

Cette version clôt le cycle de lancement de la suite de numerologie étendue avec une confiance de validation complète pour l'ensemble des langages documentés.

Numerology API — Dépréciation¶

Pour la version Numerology Extended v1.0.0, aucun endpoint de la surface étendue n'est formellement déprécié.

Numerology API — Modifications incompatibles¶

Aucune suppression de chemin incompatible n'est introduite pour la surface de numerologie étendue dans cette version.

Cependant, les intégrateurs doivent noter les attentes au niveau du déploiement suivantes :- Les points d'extrémité étendus ne sont pas disponibles via RapidAPI pour le moment. - Les clients intégrant les points d'extrémité étendus doivent cibler l'hôte de la plateforme directement. - Certains nouveaux points d'extrémité sont uniquement disponibles via POST et ne doivent pas être considérés comme ayant une compatibilité avec GET.

API de Numérologie — Notes de Migration¶

1) Migration du Canal d'Accès¶

Les points d'extrémité étendus sont disponibles via un accès direct à la plateforme :

• URL de base : https://api.numerologyapi.com
• Authentification :
• X-API-Key: YOUR_API_KEY
• ou Authorization: Bearer YOUR_API_KEY

Les points d'extrémité étendus ne sont actuellement pas pris en charge via le gateway RapidAPI.

2) Utilisation de GET vs POST¶

La plupart des points d'extrémité étendus prennent en charge à la fois GET et POST avec un objectif de sortie équivalent.

Utilisez :

• GET pour les appels basés sur des requêtes simples
• POST pour une structure de payload plus robuste, des objets imbriqués et une cohérence avec les SDK/backends

Les points d'extrémité uniquement POST dans cette version incluent :

• /api/v1/brand-name-compare
• /api/v1/relationship-composite
• /api/v1/relationship-healing-reading
• /api/v1/parent-child-numerology
• /api/v1/soul-connection-indicator

3) Règles de Validation d'Entrée du Côté Client¶

Recommandations pour la validation pré-client :- dob et target_date : YYYY-MM-DD - month : YYYY-MM - timezone_offset : Chaîne de fuseau horaire IANA valide - top_n : Entier dans la plage 1..31 - names[] : Minimum de 2 entrées pour la comparaison de marques - context pour l'alignement de date : Longueur maximale 80, alias normalisés acceptés

4) Schémas de Corps de Requête Nestés¶

Pour les points de terminaison de relations et de compatibilité, utilisez des objets imbriqués explicites tels que :

• person_a
• person_b
• parent
• child

Chaque objet doit inclure les champs requis tels que :

• full_name
• dob

5) Gestion des Langues et des Métadonnées¶

Les points de terminaison de numérologie étendus prennent en charge le rendu de réponses multilingues via lang.

Ensemble de langues prises en charge pour une couverture vérifiée :

• en
• es
• de
• fr
• pt

Les réponses peuvent inclure des enveloppes de métadonnées de style entreprise :

• _enterprise
• _api_metadata_

Les clients doivent préserver et analyser ces champs lorsque cela est utile pour l'analyse de la plateforme, les informations sur le plan ou les métadonnées du point de terminaison.

6) Couverture de Cycle Ajoutée¶

Les clients qui utilisaient auparavant uniquement les flux de jours/mois/année personnels peuvent désormais étendre la logique de planification pour couvrir :- Cycles personnels hebdomadaires via /api/v1/personal-week - Surfaces de synchronisation collectives via : - /api/v1/universal-day - /api/v1/universal-week - /api/v1/universal-month - /api/v1/universal-year

7) Source de documentation officielle¶

Les pages d'intégration complètes au niveau des points de terminaison pour cette version sont maintenues dans la section de documentation étendue, y compris les pages d'index et les pages par point de terminaison.

API de numérologie — Liste de contrôle recommandée pour la mise à niveau¶

• Déplacer les appels étendus vers un accès API direct à https://api.numerologyapi.com.
• S'assurer que les validateurs de requête appliquent les formats de date, de mois et de fuseau horaire.
• Ajouter une gestion de secours pour les valeurs multilingues lang lorsque nécessaire.
• Mettre à jour les clients pour analyser de manière cohérente _enterprise et _api_metadata_.
• Pour les points de terminaison imbriqués, aligner les modèles de requête SDK sur les clés d'objet requises.
• Valider à l'aide de fixtures de test avant de promouvoir vers la production.
• Confirmer que tous les appels étendus sont routés en dehors des hypothèses des clients basées sur RapidAPI.

API de numérologie — Résumé des notes de version¶

La version 1.0.0 de l'API de numérologie introduit la surface de numérologie étendue complète avec l'expansion des cycles hebdomadaires et universels, des analyses avancées des relations et spirituelles, des contrats de requête/réponse plus riches, ainsi qu'une documentation entièrement synchronisée et une parité de test de fumée.# Partie II — Expansion des Horoscopes v1.0.0

Principales fonctionnalités de l'Expansion des Horoscopes¶

• Migration réussie des principaux flux de rapports d'horoscopes vers le moteur Swiss Ephemeris.
• Standardisation des points d'extrémité de rapports mis à jour autour des requêtes POST.
• Couverture étendue des sections pour les périodes quotidiennes, hebdomadaires, mensuelles et annuelles.
• Restructuration des points d'extrémité de rapports planétaires par période et par équivalence section/vue d'ensemble.
• Renommage de l'endpoint du glossaire des planètes pour refléter son comportement informatif plutôt que son comportement de rapport.
• Extension de la parité des requêtes de carte natale et validation renforcée de la forme de réponse.
• Normalisation des réponses des points d'extrémité mis à jour pour inclure le payload du moteur et les wrappers de métadonnées d'entreprise.
• Mise à jour des exemples de documentation publique avec une parité JSON garantie.

Expansion des Horoscopes — Nouveaux Points d'extrémité Ajoutés¶

A) Nouvelles Surfaces et Fonctions d'Aide¶

• GET /api/v1/horoscope/timezones

B) Suite de Rapports Planétaires (Surface Périodisée)¶

Sections (non générales) :

• POST /api/v1/horoscope/reports/planetary/daily
• POST /api/v1/horoscope/reports/planetary/weekly
• POST /api/v1/horoscope/reports/planetary/monthly
• POST /api/v1/horoscope/reports/planetary/yearly

Vue d'ensemble (uniquement générale) :

• POST /api/v1/horoscope/reports/planetary/daily/overview
• POST /api/v1/horoscope/reports/planetary/weekly/overview
• POST /api/v1/horoscope/reports/planetary/monthly/overview
• POST /api/v1/horoscope/reports/planetary/yearly/overview

L'extension de la couverture des sections planétaires sur les périodes inclut les sections prises en charge par le moteur, telles que :- communication - friendship - lifestyle - career - health - money - love_singles - love_couples

C) Suite de rapports d'aspect (Surface périodique)¶

Sections (non générales) :

• POST /api/v1/horoscope/reports/aspects/daily
• POST /api/v1/horoscope/reports/aspects/weekly
• POST /api/v1/horoscope/reports/aspects/monthly
• POST /api/v1/horoscope/reports/aspects/yearly

Vue d'ensemble (uniquement générale) :

• POST /api/v1/horoscope/reports/aspects/daily/overview
• POST /api/v1/horoscope/reports/aspects/weekly/overview
• POST /api/v1/horoscope/reports/aspects/monthly/overview
• POST /api/v1/horoscope/reports/aspects/yearly/overview

aspects/* prend en charge :

• le mode public
• le mode personnalisé
• la possibilité de remplacer de manière déterministe aspect
• le même modèle de section utilisé sur les routes de horoscope mises à niveau

D) Suite de rapports de transit (Surface périodique)¶

Sections (non générales) :

• POST /api/v1/horoscope/reports/transits/daily
• POST /api/v1/horoscope/reports/transits/weekly
• POST /api/v1/horoscope/reports/transits/monthly
• POST /api/v1/horoscope/reports/transits/yearly

Vue d'ensemble (uniquement générale) :

• POST /api/v1/horoscope/reports/transits/daily/overview
• POST /api/v1/horoscope/reports/transits/weekly/overview
• POST /api/v1/horoscope/reports/transits/monthly/overview
• POST /api/v1/horoscope/reports/transits/yearly/overview

transits/* prend en charge :

• le mode public
• le mode personnalisé
• la possibilité de remplacer de manière déterministe transit
• le même modèle de section utilisé sur les routes de horoscope mises à niveau

E) Suite de rapports de maisons (Uniquement personnalisé, Surface périodique)¶

Rapports de maisons (sections non générales) :

• POST /api/v1/horoscope/reports/house/daily
• POST /api/v1/horoscope/reports/house/weekly
• POST /api/v1/horoscope/reports/house/monthly
• POST /api/v1/horoscope/reports/house/yearly

Aperçus de maisons (uniquement générale) :

• POST /api/v1/horoscope/reports/house/daily/overview
• POST /api/v1/horoscope/reports/house/weekly/overview
• POST /api/v1/horoscope/reports/house/monthly/overview
• POST /api/v1/horoscope/reports/house/yearly/overview

Rapports planète-maisons (sections non générales) :

• POST /api/v1/horoscope/reports/planet/house/daily
• POST /api/v1/horoscope/reports/planet/house/weekly
• POST /api/v1/horoscope/reports/planet/house/monthly

• POST /api/v1/horoscope/reports/planet/house/yearlyVue d'ensemble des planètes et des maisons (uniquement générales) :

• POST /api/v1/horoscope/reports/planet/house/daily/overview

• POST /api/v1/horoscope/reports/planet/house/weekly/overview
• POST /api/v1/horoscope/reports/planet/house/monthly/overview
• POST /api/v1/horoscope/reports/planet/house/yearly/overview

Les deux familles de routes sont uniquement pour la personnalisation et sont prises en charge par des points de terminaison de moteur tels que :

• /house-horoscope
• /planet-house-horoscope

F) Canonicalisation de l'espace de noms des rapports¶

Les chemins de rapports en direct canoniques utilisent désormais l'espace de noms /api/v1/horoscope/reports/* sur les surfaces de horoscope mises à jour, prises en charge par le moteur.

Les chemins de non-rapports hérités restent enregistrés comme des alias de compatibilité cachés.

G) Nouvelles familles de routes de section de horoscope ajoutées sur différentes périodes¶

Communication¶

• POST /api/v1/horoscope/reports/communication/daily/today
• POST /api/v1/horoscope/reports/communication/daily/tomorrow
• POST /api/v1/horoscope/reports/communication/daily/yesterday
• POST /api/v1/horoscope/reports/communication/weekly
• POST /api/v1/horoscope/reports/communication/monthly
• POST /api/v1/horoscope/reports/communication/yearly

Amitié¶

• POST /api/v1/horoscope/reports/friendship/daily/today
• POST /api/v1/horoscope/reports/friendship/daily/tomorrow
• POST /api/v1/horoscope/reports/friendship/daily/yesterday
• POST /api/v1/horoscope/reports/friendship/weekly
• POST /api/v1/horoscope/reports/friendship/monthly
• POST /api/v1/horoscope/reports/friendship/yearly

Style de vie¶

• POST /api/v1/horoscope/reports/lifestyle/daily/today
• POST /api/v1/horoscope/reports/lifestyle/daily/tomorrow
• POST /api/v1/horoscope/reports/lifestyle/daily/yesterday
• POST /api/v1/horoscope/reports/lifestyle/weekly
• POST /api/v1/horoscope/reports/lifestyle/monthly
• POST /api/v1/horoscope/reports/lifestyle/yearly

Surfaces de séparation amoureuse (Célibataires/Couples)¶

• POST /api/v1/horoscope/reports/love_singles/daily/today
• POST /api/v1/horoscope/reports/love_singles/daily/tomorrow
• POST /api/v1/horoscope/reports/love_singles/daily/yesterday
• POST /api/v1/horoscope/reports/love_singles/weekly
• POST /api/v1/horoscope/reports/love_singles/monthly
• POST /api/v1/horoscope/reports/love_couples/daily/today
• POST /api/v1/horoscope/reports/love_couples/daily/tomorrow
• POST /api/v1/horoscope/reports/love_couples/daily/yesterday
• POST /api/v1/horoscope/reports/love_couples/weekly
• POST /api/v1/horoscope/reports/love_couples/monthly

Ajouts de sections annuelles¶

• POST /api/v1/horoscope/reports/health/yearly
• POST /api/v1/horoscope/reports/money/yearly

H) Renommage de la surface des planètes informatives¶

• GET /api/v1/horoscope/planets-info
• POST /api/v1/horoscope/planets-info

Cela remplace le nom précédent /horoscope/planets pour le comportement de glossaire.## Expansion du Horoscope — Points d'extrémité mis à jour et corrigés

A) Migration et mises à jour du moteur¶

Les familles de points d'extrémité suivantes ont été mises à niveau vers un comportement basé sur le moteur interne :

Points d'extrémité de rapport principaux¶

• POST /api/v1/horoscope/reports/today
• POST /api/v1/horoscope/reports/yesterday
• POST /api/v1/horoscope/reports/tomorrow
• POST /api/v1/horoscope/reports/weekly
• POST /api/v1/horoscope/reports/monthly
• POST /api/v1/horoscope/reports/yearly

Familles de points d'extrémité existantes mises à niveau à partir d'un comportement horoscope.com¶

• carrière
• santé
• amour
• argent

Familles existantes et héritées restructurées et mises à niveau¶

• Les points d'extrémité d'amour hérités ont été divisés en love_singles et love_couples
• Le comportement combiné de yearly/career_money a été remplacé par des points d'extrémité dédiés pour la carrière et les revenus annuels
• Les points d'extrémité de rapport et d'aperçu de planétaires hérités ont été déplacés vers des points d'extrémité périodiques

B) Clarification de la route de description du signe astrologique¶

Les surfaces suivantes restent des points d'extrémité descriptifs de signes plutôt que des points d'extrémité de rapports en direct :

• /api/v1/horoscope/sign/personality
• /api/v1/horoscope/sign/communication
• /api/v1/horoscope/sign/friendship
• /api/v1/horoscope/sign/love
• /api/v1/horoscope/sign/lifestyle
• /api/v1/horoscope/sign/health
• /api/v1/horoscope/sign/career
• /api/v1/horoscope/sign/money
• /api/v1/horoscope/sign/parent_child
• /api/v1/horoscope/sign/spirituality
• /api/v1/horoscope/sign/shadow

C) Mise à jour de la parité du horoscope de naissance¶

POST /api/v1/horoscope/reports/birthday expose désormais les clés de requête natives du moteur tout en conservant les clés de compatibilité.

Surface mise à niveau canonique :

• POST /api/v1/horoscope/reports/birthday

Alias de compatibilité cachés conservés :- /api/v1/horoscope/birthday - /api/v1/horoscope/sign/birthday

Clés de requête natives de l'engine exposées :

• sign
• target_date
• birth
• sections
• zodiac_system
• ayanamsa
• house_system
• node_type
• tenant_id

Clés de compatibilité conservées :

• dob
• timezone
• year
• birth_time
• birth_latitude
• birth_longitude
• birth_timezone

D) Mise à jour de la parité du diagramme natal¶

Ces surfaces existaient avant la version 1.0.0 et sont désormais mises à niveau pour une meilleure compatibilité avec l'engine :

• POST /api/v1/birth-chart
• POST /api/v1/birth-chart/svg

Les améliorations comprennent :

• Prise en charge complète de l'option de requête de la passerelle vers l'engine
• Parité du champ de configuration de "wheel"
• Gardes de forme de réponse plus strictes

E) Normalisation du contrat de réponse¶

Les endpoints de l'engine de horoscope mis à niveau renvoientŸ:

• Payload de réponse de l'engine brut
• _enterprise
• _api_metadata_

F) Gestion des fuseaux horaires et des jours relatifs¶

Les endpoints quotidiens utilisant today, yesterday et tomorrow appliquent désormais la résolution de date cible consciente du fuseau horaire via l'entrée de fuseau horaire IANA.

G) Clarification du support de personnalisation¶

Lorsque cela est pris en charge, les rapports personnalisés sont activés en fournissant des champs de vecteur de naissance tels que :

• birth_time
• birth_latitude
• birth_longitude
• birth_timezone

Si ces champs sont omis, les routes restent utilisables en mode basé sur les signes.## Extension de l'API Horoscope — Points d'extrémité obsolètes, cachés et supprimés| Point de terminaison | Statut dans v1.0.0 | Remplacement | Notes ||---|---|---|---| | Route de rapport agrégé de planètes obsolète | Supprimé | Routes de période sous /reports/planetary/ avec des chemins spécifiques à la période, ainsi que les routes correspondantes /overview | Point d'entrée agrégé supprimé après la finalisation de la parité par période. || POST /api/v1/horoscope/planetary/overview | Déprécié (caché de OpenAPI) | POST /api/v1/horoscope/reports/planetary/daily/overview, POST /api/v1/horoscope/reports/planetary/weekly/overview, POST /api/v1/horoscope/reports/planetary/monthly/overview, POST /api/v1/horoscope/reports/planetary/yearly/overview | Remplacé par des routes de vue spécifiques à la période. || POST /api/v1/horoscope/planetary/daily/sections | Alias cachée | POST /api/v1/horoscope/reports/planetary/daily | Alias pour la compatibilité interne. || POST /api/v1/horoscope/love_single/monthly | Alias obsolète (cachée) | POST /api/v1/horoscope/reports/love_singles/monthly | Conserve pour la compatibilité. || POST /api/v1/horoscope/weekly/retail | Déprécié (caché de OpenAPI/docs) | Aucun | Retiré des documents publics pour le commerce de détail hebdomadaire. || Route d'horoscope flexible et évolutif | Supprimé | Routes de rapports et de vue d'ensemble spécifiques à la section | Point d'entrée agrégé supprimé après la séparation complète des points de terminaison. || POST /api/v1/horoscope/yearly/career_money | Supprimé | POST /api/v1/horoscope/reports/career/yearly et POST /api/v1/horoscope/reports/money/yearly | Endpoint combiné divisé en routes dédiées. || POST /api/v1/horoscope/love/{today,tomorrow,yesterday} | Suppression de l'inscription active | POST /api/v1/horoscope/reports/love_singles/daily/{today,tomorrow,yesterday} ou POST /api/v1/horoscope/reports/love_couples/daily/{today,tomorrow,yesterday} | L'amour quotidien est désormais divisé en fonction du contexte de la relation. || GET /api/v1/horoscope/planets et POST /api/v1/horoscope/planets | Renommées/supprimées | GET /api/v1/horoscope/planets-info et POST /api/v1/horoscope/planets-info | Renommage des points d'extrémité informatifs pour plus de clarté. |

Extension de l'Horoscope — Modifications incompatibles¶

• Renommage de l'itinéraire : /api/v1/horoscope/planets → /api/v1/horoscope/planets-info
• Le namespace canonique pour les rapports d'horoscope basés sur le moteur est maintenant /api/v1/horoscope/reports/*
• Les itinéraires quotidiens combinés sont remplacés par des chemins explicites pour les célibataires et les couples
• L'itinéraire combiné career_money annuel est supprimé en faveur d'itinéraires annuels dédiés
• Les points d'extrémité de rapport et d'aperçu planétaires génériques sont dépréciés en faveur d'itinéraires structurés par période
• Les itinéraires basés sur le moteur mis à niveau sont standardisés autour des corps de requête POST

Extension de l'Horoscope — Notes de compatibilité¶

• Les itinéraires hérités /api/v1/horoscope/report/* restent disponibles en tant qu'alias cachés et rétrocompatibles
• La documentation publique et OpenAPI présentent désormais uniquement le namespace canonique /api/v1/horoscope/reports/*
• Les nouvelles intégrations devraient adopter immédiatement les chemins /reports/*

Extension de l'Horoscope — Notes de migration¶

1) Carte de migration des chemins d'extrémité- GET/POST /api/v1/horoscope/planets → GET/POST /api/v1/horoscope/planets-info¶

• POST /api/v1/horoscope/report/{surface} → POST /api/v1/horoscope/reports/{surface}
• POST /api/v1/horoscope/{surface} → POST /api/v1/horoscope/reports/{surface}
• POST /api/v1/horoscope/planetary/overview → POST /api/v1/horoscope/reports/planetary/{period}/overview
• Itinéraire d'agrégation planétaire existant → POST /api/v1/horoscope/reports/planetary/{period} ou itinéraire équivalent de vue d'ensemble
• Itinéraire d'agrégation horoscopique flexible existant → Itinéraires spécifiques à la section ou itinéraires de vue d'ensemble
• POST /api/v1/horoscope/yearly/career_money → Diviser en itinéraires de carrière annuels et annuels pour l'argent
• Itinéraires quotidiens de l'amour existants → Diviser en itinéraires quotidiens love_singles ou love_couples

2) Migration du corps de requête¶

Pour les itinéraires mis à niveau, utilisez des corps POST structurés avec des champs tels que :

• dob
• timezone
• Sélecteurs de période tels que day, target_date ou year
• Options de moteur facultatives :
• zodiac_system
• ayanamsa
• house_system
• node_type
• tenant_id
• Champs de personnalisation facultatifs :
• birth_time
• birth_latitude
• birth_longitude
• birth_timezone

3) Règles de migration des itinéraires planétaires¶

• Utilisez sections uniquement sur les itinéraires périodiques planétaires non de type vue d'ensemble
• general est accessible via des itinéraires dédiés /overview

4) Migration du parseur de réponse¶

Les clients doivent parser :

• Les champs du corps de requête directement à partir du corps de réponse
• _enterprise
• _api_metadata_

5) Note sur le comportement de la traductionThe horoscope engine itself does not generate multilingual content directly, so report based endpoints currently support but en only.¶

Non-report endpoints continue to support full multilingual translation through gateway helper layers using lang, such as:

• en
• es
• de
• fr
• pt

Expansion de l'API Horoscope — Documentation et Parité QA Complétées¶

• Documentation publique mise à jour pour les nouvelles routes de prévisions astrologiques

---- Documentation des planètes héritée remplacée par des documentation des planètes spécifiques à une période

---- Séparation de la documentation sur la carrière et les finances, avec suppression des routes combinées

---- Exemple JSON avec des données "Smoke-backed" synchronisées avec les réponses des points de terminaison pour une documentation améliorée

---¶

Vérification de mise à niveau du client recommandée pour l'Horoscope API¶

• Mettre à jour tous les chemins renommés et obsolètes en utilisant le plan de migration

--- FIN MARKDOWN ---- Passer tous les consommateurs GET hérités des nouvelles routes de rapport vers des requêtes de corps POST

--- FIN MARKDOWN ---- Ajouter le fuseau horaire à tous les flux quotidiens pour éviter le décalage des dates relatives

--- FIN MARKDOWN ---- Ajouter des champs de personnalisation lorsque des éditoriaux spécifiques à l'utilisateur sont souhaités

--- FIN MARKDOWN ---- Mettre à jour les parseurs de réponse pour conserver _enterprise et _api_metadata_- Réexécuter les tests d'intégration contre tous les points de terminaison de horoscope utilisés en production

---¶

Résumé des notes de version — Horoscope Expansion¶

La version 1.0.0 de l'API Numerology met en œuvre une mise à jour majeure pour assurer la compatibilité avec le moteur, étend la couverture des rapports sur les différentes sections et périodes, introduit une structure de route plus claire et établit une surface de production plus claire pour les futures itérations du moteur d'horoscope interne.

Partie III — Instructions d'intégration multi-API¶

Notes d'intégration unifiées pour les clients utilisant l'API Numerology¶

Les clients qui consomment à la fois les points de terminaison Numerology et les points de terminaison Horoscope doivent examiner les éléments suivants ensemble :

Authentification et accès¶

• Les points de terminaison Numerology étendus sont uniquement compatibles avec la plateforme (sans support pour le gateway RapidAPI)
• Les routes du moteur pour les horoscopes sont également uniquement compatibles avec la plateforme et continuent de fonctionner sous leur propre espace de noms API avec des schémas de gateway mis à jour
• Préserver le support pour les wrappers de métadonnées de type entreprise

Modélisation des requêtes¶

• Privilégier les corps POST structurés explicites pour tous les nouveaux points de terminaison mis à jour ou étendus
• Valider les formats de date, les sélecteurs de période, les chaînes de fuseau horaire et les objets imbriqués côté client
• Fournir des vecteurs de personnalisation pour des sorties plus riches, lorsque cela est disponible.### Heure et Sémantique de la Date
• Les points d'extrémité de Numerology dépendent de formats de date et de mois corrects
• Les points d'extrémité quotidiens de Horoscope dépendent d'une gestion correcte du fuseau horaire pour la résolution relative des jours
• Les chaînes de fuseaux horaires IANA sont fortement recommandées, si elles sont prises en charge

Gestion des Langues¶

• Les points d'extrémité étendus de Numerology ont un rendu multilingue vérifié
• Les points d'extrémité de horoscope, pris en charge par l'Engine, continuent de prendre en charge uniquement en

Conseils pour le Déploiement en Production¶

• Mettez à jour d'abord les SDK et les validateurs de requêtes
• Rafraîchissez ensuite les tests d'intégration
• Ensuite, déployez les modifications des points de terminaison/des chemins auprès des clients de production
• Surveillez toute alias de compatibilité cachée encore utilisée en interne afin de pouvoir la supprimer en toute confiance plus tard

Partie IV — Résumé de la Version Finale¶

Ce que signifie v1.0.0¶

v1.0.0 est le point où les deux surfaces deviennent considérablement plus complètes et adaptées à la production :- Numerology API expose désormais un catalogue beaucoup plus riche et étendu, couvrant la temporalité, l'identité, la compréhension spirituelle, le travail sur les ombres, les relations, la compatibilité et les calendriers prédictifs. - Les rapports astrologiques reposent désormais sur une base beaucoup plus solide, avec des espaces de noms de rapports canoniques, une couverture plus large des sections, des schémas de migration plus clairs et une meilleure cohérence entre les familles de rapports. - La documentation, les exemples, le comportement de validation et les conseils de compatibilité sont beaucoup plus matures que dans l'état pré-v1.0.0.

Cette version n'est pas qu'une simple mise à jour. C'est une version qui améliore :

• la complétude de la plateforme
• la clarté des routes
• la préparation à la migration des clients
• la confiance dans la documentation
• la cohérence de l'intégration d'entreprise

Recommandation Opérationnelle¶

Pour tous les intégrateurs actifs, la voie recommandée est la suivante :

1. adopter immédiatement les routes canoniques
2. mettre à jour les modèles de requête pour les payloads POST lorsque cela est applicable
3. préserver le parsing du wrapper de métadonnées
4. valider les formats de fuseau horaire/date côté client
5. déplacer les consommateurs étendus de Numerology vers un accès direct à la plateforme
6. relancer les tests de couverture d'intégration complète avant le déploiement en production

Note FinaleThis unified changelog reflects the v1.0.0 release state for The Numerology API and consolidates the major rollout work completed for the 2026-04-12 release window.¶