# Applications astrologiques

Tu construis une application Astro comme Co-Star, Sanctuary, The Pattern, Chani ou Costar Compat ? L’API AstroWay remplace le besoin de licencier Solar Fire ($495) ou d’écrire ton propre moteur d’éphémérides : {siteMeta.endpoints} endpoints (cartes natales, synastrie, transits, Human Design, interprétations IA), OpenAPI 3.1 pour générer des clients typés (SDK TS/Python en roadmap), précision Swiss Ephemeris — le même moteur qu’Astrodienst et Kepler.

## Architecture typique

```
Utilisateur (navigateur / mobile)
     ↓
Ton backend (Node.js / Python / PHP)
     ↓ HTTPS + X-Api-Key
api.astroway.info/v1/*
     ↓
Réponse JSON → rendu dans ton interface
```

<Aside type="caution">
Ne place **jamais** ta clé API dans le code frontend. Les appels à l’API AstroWay doivent transiter par ton backend ou des fonctions serveur (routes API Next.js, fonctions Vercel, AWS Lambda).
</Aside>

## Endpoints clés pour une appli astro

### MVP (produit minimal viable)

| Endpoint | Crédits | Pour quoi faire |
|---|---|---|
| `/v1/chart` | 20 | Générer une carte natale |
| `/v1/synastry` | 50 | Compatibilité entre deux personnes |
| `/v1/horoscope/daily` | 20 | Horoscope quotidien |

Trois endpoints, et tu as déjà une appli fonctionnelle avec carte natale, compatibilité et contenu quotidien.

### Produit avancé

| Endpoint | Crédits | Pour quoi faire |
|---|---|---|
| `/v1/transits` | 50 | Transits actuels sur une carte natale |
| `/v1/solar-return` | 50 | Carte solaire (annuelle) |
| `/v1/progressions` | 50 | Progressions secondaires |
| `/v1/interpret/natal` | 50 | Interprétation IA d’une carte natale |
| `/v1/transit-calendar` | 100 | Calendrier d’événements transitifs |
| `/v1/human-design` | 50 | Carte Human Design |

### Fonctionnalités premium

| Endpoint | Crédits | Pour quoi faire |
|---|---|---|
| `/v1/rectification` | 500 | Rectification de l’heure de naissance |
| `/v1/acg` | 50 | Astro-cartographie (où vivre) |
| `/v1/forecast-calendar` | 100 | Calendrier de prévisions (heatmap annuelle) |
| `/v1/group-synastry` | 100 | Compatibilité de groupe |

## Estimation de budget

### Scénario : 100 utilisateurs actifs par jour (DAU)

On suppose qu’un utilisateur moyen effectue 3 actions par jour :

| Action | Endpoint | Crédits | Requêtes/jour | Crédits/jour |
|---|---|---|---|---|
| Afficher une carte | `/v1/chart` | 20 | 100 | 2 000 |
| Horoscope quotidien | `/v1/horoscope/daily` | 20 | 100 | 2 000 |
| Compatibilité | `/v1/synastry` | 50 | 30 | 1 500 |
| **Total** | | | **230** | **5 500/jour** |

**~165 000 crédits/mois** (5 500 × 30) → forfait **Starter ($19/mois, 200 000 crédits)** avec 21 % de marge, ou **Indie ($5/mois, 50 000)** avec paiement des dépassements ~$5 pour 110K crédits supplémentaires.

### Scénario : MVP avec 20 DAU

| Action | Crédits/jour |
|---|---|
| 20 cartes | 400 |
| 20 horoscopes | 400 |
| 5 compatibilités | 250 |
| **Total** | **1 050/jour** |

**~31 500 crédits/mois** → forfait **Indie ($5/mois, 50 000 crédits)**.

## Conseils

- **Cache les cartes natales** — l’entrée est immuable (la date de naissance ne change pas), tu peux donc mettre le résultat en cache à vie dans ta base de données.
- **Cache les horoscopes par jour** — l’horoscope quotidien est identique pour tous les natifs d’un même signe, génère-le une fois et redistribue-le.
- **Clés sandbox** (`aw_test_*`) — pour le développement, elles ne consomment pas de crédits.
- **Génération de code avec OpenAPI 3.1** — envoie `/v1/openapi.json` à `openapi-typescript` ou `openapi-python-client` et récupère un client typé (SDK prêts à l’emploi en roadmap).

<CardGrid>
  <LinkCard title="Démarrage rapide →" href="/getting-started/" description="Première requête en 5 minutes" />
  <LinkCard title="API de carte natale" href="/products/birth-chart-api/" description="Détails sur la carte natale" />
  <LinkCard title="Tarifs" href="/pricing/" description="Du gratuit à l’Enterprise" />
</CardGrid>