Authentifizierung

client_credentials ist der Weg für Programme, die für sich selbst handeln. Es gibt keinen Zustimmungsdialog und keinen Refresh-Token.

• Zugang im Dashboard anlegen: Konto → API-Zugang. Das client_secret wird einmal angezeigt und ist danach nicht mehr abrufbar.
• POST /v1/oauth/token mit client_id und client_secret. Die Antwort enthält access_token, expires_in (3600) und die bewilligten Rechte.
• Token als Authorization: Bearer ACCESS_TOKEN an jedem Aufruf mitschicken. Nach Ablauf antwortet die API mit 401 und dem Code token_expired.

curl -X POST https://open-api.mynextdays.com/v1/oauth/token \
  -H 'Content-Type: application/json' \
  -d '{
    "grant_type": "client_credentials",
    "client_id": "mnd_live_id_…",
    "client_secret": "mnd_live_…"
  }'

{
  "access_token": "eyJhbGciOiJIUzI1NiIs…",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "properties:read availability:read reservations:read"
}

Token im Speicher halten, nicht je Aufruf neu holen. Ein Tausch je Anfrage läuft in die Ratenbegrenzung des Token-Endpunkts (10/Minute).

Rechte haben die Form bereich:richtung, etwa reservations:read oder rates:write. Fehlt ein Recht, antwortet der Endpunkt mit 403 und dem Code insufficient_scope.

Nur die Rechte vergeben, die die Integration braucht. Ein verlorener Schlüssel kann dann nichts überschreiben, was er nie lesen sollte.

Ein Zugang kann auf bestimmte Objekte beschränkt sein. Er sieht in Listen nur diese; ein Aufruf mit einer anderen Objekt-ID antwortet mit 403 und dem Code objekt_nicht_erlaubt.

GET /v1/me liefert Betrieb, Rechte und Objekt-Beschränkung des Tokens — der erste Aufruf beim Einrichten einer Integration.