# Migration von V1

Die V2 API ändert das Grundprinzip: Statt jede Anfrage über URL-Parameter zu konfigurieren,
legen Sie **Standorte (Sites)** an und fragen sie über ihre `site_id` ab.

:::note
Die V1 API bleibt unverändert und weiterhin verfügbar. Sie müssen **nicht** sofort migrieren —
dieser Leitfaden hilft beim Umstieg, wenn Sie die V2-Vorteile nutzen möchten. Die V1 API wird voraussichtlich am
**31.12.2026** abgeschaltet.
:::

## Das neue Grundprinzip

|                             | V1                                  | V2                                  |
|-----------------------------|-------------------------------------|-------------------------------------|
| Konfiguration               | Pro Anfrage in der URL              | Einmal als Standort gespeichert     |
| Abfrage                     | `/v1/forecast?latitude=…&slope=…`   | `/v2/forecast/{site_id}`            |
| Strings                     | Ein bis zwei Strings über Parameter | Mehrere `strings` pro Standort      |
| Höhe/Zeitzone/Geländeprofil | Pro Anfrage & Bedarf berechnet      | Automatisch ermittelt & gespeichert |

Für Anwendungsfälle ohne persistente Standorte (z. B. einmalige Berechnungen) gibt es die
[Inline-Endpunkte](/de/v2/enterprise/inline), die der alten URL-Logik am nächsten kommen.

## Endpunkt-Mapping

| V1                      | V2                                                               |
|-------------------------|------------------------------------------------------------------|
| `GET /v1/forecast?…`    | `GET /v2/forecast/{site_id}` oder `POST /v2/forecast/inline`     |
| `GET /v1/history?…`     | `GET /v2/historical/{site_id}` oder `POST /v2/historical/inline` |
| `GET /v1/recent?…`      | In `GET /v2/historical/{site_id}` enthalten                      |
| (keine Site-Verwaltung) | `POST/GET/PATCH/DELETE /v2/sites`                                |

In V2 sind **`/recent` und `/history` zu einem Endpunkt verschmolzen**.

## Feldnamen & Antwortformat

Die V2 nutzt durchgängig klare Feldnamen und lokale Zeitstempel.

| V1                     | V2                                                   |
|------------------------|------------------------------------------------------|
| `dtm` (UTC)            | `timestamp` (lokale ISO-8601-Zeit, siehe `timezone`) |
| `spec_watts` (W/kWp)   | entfällt — V2 liefert direkt `pv_power` in W         |
| `pv_watts`             | `pv_power` (W)                                       |
| `GHI` / `DHI` / `BNI`  | `ghi` / `dhi` / `bni`                                |
| `temp`, `weather_code` | `temp`, `weather_code` (unverändert benannt)         |

Wichtige Unterschiede:

- **Zeitstempel sind lokal**, nicht UTC. Die IANA-Zeitzone steht im Feld `timezone`.
- **`gti` / `gti_shaded` sind pro String** und liegen im `strings`-Block (geneigte Einstrahlung
  hängt von der Ausrichtung ab) — siehe [Prognosen](/de/v2/api/forecast).
- `spec_power` / `spec_watts` wird **nicht mehr ausgegeben**; nutzen Sie `pv_power`.

## `required_data` → `include`-Gruppen

Statt einer freien Spaltenliste (`required_data=pv_watts,temp`) wählen Sie in V2
**Feldgruppen** über den wiederholbaren `include`-Parameter:

```bash title="V1"
GET /v1/forecast?required_data=pv_watts,temp,GHI
```

```bash title="V2"
GET /v2/forecast/{site_id}?include=weather&include=irradiance
```

Verfügbare Gruppen: `default`, `weather`, `irradiance`, `clearsky`, `strings`, `variability`,
`all`. Details unter [Prognosen](/de/v2/api/forecast).

## Migrationsschritte

1. **API-Key** weiterverwenden — derselbe Key funktioniert für V1 und V2.
2. Für jede bisherige Parameter-Kombination **einen Standort anlegen** (`POST /v2/sites`).
3. Abfragen auf `GET /v2/forecast/{site_id}` bzw. `GET /v2/historical/{site_id}` umstellen.
4. Im Code die **neuen Feldnamen** und **lokalen Zeitstempel** berücksichtigen.
5. `required_data` durch passende `include`-Gruppen ersetzen.

Die vollständige Endpunkt- und Feldreferenz finden Sie in der [API-Referenz](/api).

## Migration von Integrationen

Wenn Sie eine Integration wie Solectrus, EVCC oder ioBroker verwenden, müssen Sie auf ein Update der jeweiligen
Integration warten, bevor Sie auf die V2 wechseln können. Wir werden den Fortschritt der
Entwicklung [hier](/de/v2/integrations/index) hinterlegen.