# Aplikacje astrologiczne

Budujesz aplikację astrologiczną w stylu Co-Star, Sanctuary, The Pattern, Chani czy Costar Compat? AstroWay API eliminuje potrzebę licencjonowania Solar Fire ($495) lub pisania własnego silnika efemeryd: {siteMeta.endpoints} endpointów (karty natalne, synastria, tranzyty, Human Design, interpretacje AI), OpenAPI 3.1 do generowania typowanych klientów (TS / Python SDK w roadmapie), dokładność Swiss Ephemeris — ten sam silnik, który używany jest w Astrodienst i Kepler.

## Typowa architektura

```
Użytkownik (przeglądarka / mobilny)
     ↓
Twój backend (Node.js / Python / PHP)
     ↓ HTTPS + X-Api-Key
api.astroway.info/v1/*
     ↓
Odpowiedź JSON → renderowanie w Twoim UI
```

<Aside type="caution">
Nigdy nie umieszczaj klucza API w kodzie frontendowym. Wywołania API AstroWay muszą przechodzić przez Twój backend lub funkcje serwerowe (ścieżki API Next.js, funkcje Vercel, AWS Lambda).
</Aside>

## Kluczowe endpointy dla aplikacji astrologicznej

### MVP (produkt minimalny)

| Endpoint | Kredyty | Do czego |
|---|---|---|
| `/v1/chart` | 20 | Budowanie karty natalnej |
| `/v1/synastry` | 50 | Kompatybilność dwóch osób |
| `/v1/horoscope/daily` | 20 | Codzienny horoskop |

Trzy endpointy — i już masz działający produkt z kartą natalną, kompatybilnością i codziennym contentem.

### Rozszerzony produkt

| Endpoint | Kredyty | Do czego |
|---|---|---|
| `/v1/transits` | 50 | Aktualne tranzyty na kartę natalną |
| `/v1/solar-return` | 50 | Solar (roczna karta) |
| `/v1/progressions` | 50 | Drugorzędne progresje |
| `/v1/interpret/natal` | 50 | Interpretacja AI karty natalnej |
| `/v1/transit-calendar` | 100 | Kalendarz tranzytywnych wydarzeń |
| `/v1/human-design` | 50 | Karta HD |

### Funkcje premium

| Endpoint | Kredyty | Do czego |
|---|---|---|
| `/v1/rectification` | 500 | Korekta czasu urodzenia |
| `/v1/acg` | 50 | Astrokartografia (gdzie lepiej mieszkać) |
| `/v1/forecast-calendar` | 100 | Roczna prognoza-heatmap |
| `/v1/group-synastry` | 100 | Kompatybilność grupowa |

## Szacowanie budżetu

### Scenariusz: 100 DAU (dziennie aktywnych użytkowników)

Przyjmujemy, że średni użytkownik wykonuje 3 akcje dziennie:

| Akcja | Endpoint | Kredyty | Zapytania/dzień | Kredytów/dzień |
|---|---|---|---|---|
| Przeglądanie karty | `/v1/chart` | 20 | 100 | 2 000 |
| Codzienny horoskop | `/v1/horoscope/daily` | 20 | 100 | 2 000 |
| Kompatybilność | `/v1/synastry` | 50 | 30 | 1 500 |
| **Razem** | | | **230** | **5 500/dzień** |

**~165 000 kredytów/miesiąc** (5 500 × 30) → plan **Starter ($19/mies., 200 000 kredytów)** z 21% zapasem, lub **Indie ($5/mies., 50 000)** z opłatą overage ~$5 za dodatkowe 110K kredytów.

### Scenariusz: MVP z 20 DAU

| Akcja | Kredytów/dzień |
|---|---|
| 20 kart | 400 |
| 20 horoskopów | 400 |
| 5 synastrii | 250 |
| **Razem** | **1 050/dzień** |

**~31 500 kredytów/miesiąc** → plan **Indie ($5/mies., 50 000 kredytów)**.

## Porady

- **Kasuj karty natalne** — dane wejściowe są niezmienne (data urodzenia się nie zmienia), więc wynik można kasować na zawsze w swojej bazie danych
- **Kasuj horoskopy na dzień** — codzienny horoskop jest taki sam dla wszystkich osób jednego znaku, generuj raz i rozdawaj
- **Klucze sandbox** (`aw_test_*`) — do rozwoju, nie zużywają kredytów
- **Generowanie kodu z OpenAPI 3.1** — wrzuć `/v1/openapi.json` do `openapi-typescript` lub `openapi-python-client` i uzyskaj typowanego klienta (gotowe SDK w roadmapie)

<CardGrid>
  <LinkCard title="Szybki start →" href="/getting-started/" description="Pierwsze zapytanie w 5 minut" />
  <LinkCard title="Birth Chart API" href="/products/birth-chart-api/" description="Szczegóły o karcie natalnej" />
  <LinkCard title="Cennik" href="/pricing/" description="Od darmowego do Enterprise" />
</CardGrid>
