# Astrologie-Apps

Baust du eine Astro-App wie Co-Star, Sanctuary, The Pattern, Chani oder Costar Compat? Die AstroWay-API ersetzt die Notwendigkeit, Solar Fire ($495) zu lizenzieren oder deine eigene Ephemeriden-Engine zu schreiben: {siteMeta.endpoints} Endpunkte (Geburtskarten, Synastrie, Transite, Human Design, KI-Interpretationen), OpenAPI 3.1 zur Generierung typisierter Clients (TS/Python-SDK in der Roadmap), Swiss Ephemeris – dieselbe Engine, die auch bei Astrodienst und Kepler verwendet wird.

## Typische Architektur

```
Nutzer:in (Browser / Mobile)
     ↓
Dein Backend (Node.js / Python / PHP)
     ↓ HTTPS + X-Api-Key
api.astroway.info/v1/*
     ↓
JSON-Antwort → Rendering in deiner UI
```

<Aside type="caution">
Lege niemals API-Schlüssel im Frontend-Code ab. Aufrufe der AstroWay-API müssen über dein Backend oder Serverfunktionen laufen (Next.js API-Routen, Vercel Functions, AWS Lambda).
</Aside>

## Wichtige Endpunkte für deine Astro-App

### MVP (Minimal Viable Product)

| Endpunkt | Credits | Wofür |
|---|---|---|
| `/v1/chart` | 20 | Erstellung einer Geburtskarte |
| `/v1/synastry` | 50 | Kompatibilität zweier Personen |
| `/v1/horoscope/daily` | 20 | Tageshoroskop |

Drei Endpunkte – und schon hast du ein funktionierendes Produkt mit Geburtskarte, Kompatibilität und täglichem Content.

### Erweiterte Funktionen

| Endpunkt | Credits | Wofür |
|---|---|---|
| `/v1/transits` | 50 | Aktuelle Transite zur Geburtskarte |
| `/v1/solar-return` | 50 | Solarkarte (jährliche Karte) |
| `/v1/progressions` | 50 | Sekundäre Progressionen |
| `/v1/interpret/natal` | 50 | KI-Interpretation der Geburtskarte |
| `/v1/transit-calendar` | 100 | Kalender mit Transit-Ereignissen |
| `/v1/human-design` | 50 | HD-Karte |

### Premium-Funktionen

| Endpunkt | Credits | Wofür |
|---|---|---|
| `/v1/rectification` | 500 | Geburtszeitkorrektur |
| `/v1/acg` | 50 | Astrokartografie (wo man besser lebt) |
| `/v1/forecast-calendar` | 100 | Jahresprognose-Heatmap |
| `/v1/group-synastry` | 100 | Gruppenkompatibilität |

## Budgetabschätzung

### Szenario: 100 DAU (daily active users)

Wir gehen davon aus, dass Nutzer:innen durchschnittlich 3 Aktionen pro Tag durchführen:

| Aktion | Endpunkt | Credits | Anfragen/Tag | Credits/Tag |
|---|---|---|---|---|
| Kartenansicht | `/v1/chart` | 20 | 100 | 2 000 |
| Tageshoroskop | `/v1/horoscope/daily` | 20 | 100 | 2 000 |
| Kompatibilität | `/v1/synastry` | 50 | 30 | 1 500 |
| **Gesamt** | | | **230** | **5 500/Tag** |

**~165 000 Credits/Monat** (5 500 × 30) → Tarif **Starter ($19/Monat, 200 000 Credits)** mit 21 % Puffer oder **Indie ($5/Monat, 50 000 Credits)** mit zusätzlichen Kosten von ~$5 für die überschüssigen 110K Credits.

### Szenario: MVP mit 20 DAU

| Aktion | Credits/Tag |
|---|---|
| 20 Karten | 400 |
| 20 Horoskope | 400 |
| 5 Synastrie-Berechnungen | 250 |
| **Gesamt** | **1 050/Tag** |

**~31 500 Credits/Monat** → Tarif **Indie ($5/Monat, 50 000 Credits)**.

## Tipps

- **Kasche Geburtskarten** – die Eingabe ist unveränderlich (Geburtsdatum ändert sich nicht), daher kannst du das Ergebnis dauerhaft in deiner Datenbank zwischenspeichern
- **Horoskope täglich zwischenspeichern** – das Tageshoroskop ist für alle Menschen desselben Zeichens identisch, generiere es einmal und verteile es
- **Sandbox-Schlüssel** (`aw_test_*`) – für die Entwicklung, verbrauchen keine Credits
- **Code-Generierung mit OpenAPI 3.1** – gib `/v1/openapi.json` in `openapi-typescript` oder `openapi-python-client` ein und erhalte einen typisierten Client (fertige SDKs sind in der Roadmap)

<CardGrid>
  <LinkCard title="Schnellstart →" href="/getting-started/" description="Erster Request in 5 Minuten" />
  <LinkCard title="Birth Chart API" href="/products/birth-chart-api/" description="Details zur Geburtskarte" />
  <LinkCard title="Preise" href="/pricing/" description="Von kostenlos bis Enterprise" />
</CardGrid>