# Messaging API v2 Übersicht

Die Messaging API v2 ist ein einzelner REST/JSON-Endpunkt zum Erstellen ausgehender Nachrichten über jeden von Pushwoosh unterstützten Kanal:

- Push: iOS, Android, Huawei, Baidu, macOS, Amazon, Windows, Safari, Chrome, Firefox, IE
- E-Mail
- SMS
- Telegram, Kakao, LINE, WhatsApp, Viber

Der **Kanal** wird durch den Payload-Typ ausgewählt (`payload` für Push / SMS / Messenger, `email_payload` für E-Mail).

Das **Targeting** wird durch die Art der Anfrage ausgewählt (`segment` für Zielgruppensegmente, `transactional` für explizite Geräte- oder Benutzerlisten).

## Basis-URL

```
https://api.pushwoosh.com
```

Wenn Sie eine dedizierte Region oder eine private Bereitstellung verwenden, bestätigen Sie die genaue Basis-URL mit Ihrem Pushwoosh Customer Success Manager.

## Authentifizierung

Jede Anfrage muss einen `Authorization`-Header mit einem serverseitigen Pushwoosh [API-Zugriffstoken](/de/developer/api-reference/api-access-token/#server-api-token) enthalten:

```
Authorization: Token YOUR_API_TOKEN
```

Verwenden Sie dasselbe Token, das Sie bereits für Server-zu-Server-API-Aufrufe ausstellen. Geben Sie dieses Token nicht in Client-Anwendungen preis.

## Methoden

- [`Notify`](/de/developer/api-reference/messaging-api-v2/notify/): `POST /messaging/v2/notify`. Erstellen und senden Sie eine einzelne Nachricht (Segment oder transaktional).
- [`Cancel`](/de/developer/api-reference/messaging-api-v2/cancel/): `POST /messaging/v2/cancel`. Stornieren Sie eine zuvor erstellte Nachricht, die noch nicht zugestellt wurde.
- [`Update`](/de/developer/api-reference/messaging-api-v2/update/): `POST /messaging/v2/update`. Ersetzen Sie eine noch geplante Nachricht durch eine neue Definition.

## Anfrage- und Antwortformat

- Inhaltstyp: `application/json`.
- Feldnamen verwenden `snake_case`. `oneof`-Gruppen erscheinen als verschachtelte Objekte mit genau einem gesetzten Schlüssel.
- Enum-Werte werden als ihre String-Namen serialisiert (zum Beispiel `"IOS"`, `"MESSAGE_TYPE_MARKETING"`).
- Erfolgreiche Antworten geben HTTP 200 mit einem JSON-Body zurück; Fehler verwenden den Standard-gRPC-Gateway-Fehlerumschlag — `{ "code": ..., "message": ..., "details": [...] }`.

## Schnellstart

```bash title="Eine Push-Benachrichtigung an ein Segment senden"
curl -X POST https://api.pushwoosh.com/messaging/v2/notify \
  -H "Authorization: Token YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "segment": {
      "application": "XXXXX-XXXXX",
      "platforms": ["IOS", "ANDROID"],
      "code": "active_users",
      "payload": {
        "content": {
          "localized_content": {
            "en": {
              "ios":     { "body": "Hello from v2!" },
              "android": { "body": "Hello from v2!" }
            }
          }
        }
      },
      "schedule": { "at": "2026-05-01T12:00:00Z" },
      "message_type": "MESSAGE_TYPE_MARKETING"
    }
  }'
```

## Senden von E-Mails über SMTP

Wenn ein Dienst bereits SMTP spricht, können Sie transaktionale E-Mails über das [SMTP-Gateway](/de/developer/api-reference/smtp-gateway/) senden, anstatt `Notify` direkt aufzurufen. Das Gateway leitet jede Nachricht an diese API als transaktionales `Notify` weiter, sodass dieselben Authentifizierungs- und E-Mail-Payload-Regeln gelten.

## Nächste Schritte

<CardGrid>
  <LinkCard title="Notify" href="/developer/api-reference/messaging-api-v2/notify/" />
  <LinkCard title="Cancel" href="/developer/api-reference/messaging-api-v2/cancel/" />
  <LinkCard title="Update" href="/developer/api-reference/messaging-api-v2/update/" />
  <LinkCard title="Payload-Referenz" href="/developer/api-reference/messaging-api-v2/payload-reference/" />
  <LinkCard title="E-Mail-Payload-Referenz" href="/developer/api-reference/messaging-api-v2/email-payload-reference/" />
  <LinkCard title="SMTP-Gateway" href="/developer/api-reference/smtp-gateway/" />
  <LinkCard title="Migration von v1" href="/developer/api-reference/messaging-api-v2/migration-from-v1/" />
</CardGrid>