POST/api/auth/forgot-password

Löst den Versand einer Passwort-Reset-E-Mail aus, sofern ein Konto mit dieser Adresse existiert. Antwortet bewusst immer gleich (kein Rückschluss auf Existenz des Kontos möglich).

Die Seite „POST /api/auth/forgot-password — API-Referenz“ behandelt den in der URL bezeichneten Funktionsbereich. Der vorhandene Inhalt wird um den tatsächlichen Ablauf, die Voraussetzungen und die bekannten Grenzen ergänzt. Zentor besitzt kein Entwickler-API-Key-System. Für das Dashboard werden Session-JWTs mit zwölf Stunden Laufzeit und Refresh-Tokens mit sieben Tagen Laufzeit verwendet; TOTP und SSO sind optional. Widget-Embed-Tokens werden einmalig im Klartext angezeigt und sind an zugelassene Origins gebunden. Die Dokumentation zu `POST /api/auth/forgot-password` soll verbindlich als technische Beschreibung dieses konkreten Endpunkts gelesen werden. Entscheidend sind Methode, Pfad, Authentifizierung, Pflichtfelder, mögliche Fehler und die Frage, ob ein erneuter Aufruf denselben Effekt auslöst. Dieser Hilfeabschnitt https://zentor-app.de/hilfe/api-referenz/auth/auth.forgot_password darf deshalb keine allgemeinen Werbeaussagen enthalten, sondern nur im Anschluss anvollziehbare Integrationsschritte und belegte Antwortbeispiele. Für einen Aufruf von `/api/auth/forgot-password` wird die Anfrage entsprechend der Registry aufgebaut. Öffentliche Routen benötigen keinen allgemeinen Entwickler-API-Schlüssel, weil Zentor kein solches Schlüsselsystem anbietet. Geschützte Widget-Routen verwenden dagegen den einmalig angezeigten Embed-Token und eine Origin-Prüfung. Der HTTP-Status und der JSON-Inhalt müssen gemeinsam ausgewertet werden; ein `ok`-Feld allein ersetzt keine Fehlerbehandlung. Beim Test von `POST /api/auth/forgot-password` sind anonymisierte Werte zu verwenden. Reale Kundendaten, produktive UUIDs, Sitzungs-Tokens und konkrete Zeitstempel gehören nicht in öffentliche Beispiele. Der bekannte plattformweite Grenzwert liegt bei 2.000 Anfragen innerhalb von 15 Minuten; ein abweichendes Einzellimit ist nicht belegt. Nicht idempotente POST-Aufrufe dürfen nach einem unklaren Netzwerkabbruch nicht blind wiederholt werden. Typische Integrationsfehler für diese Route entstehen durch fehlende Pflichtparameter, falsche Datentypen, abgelaufene Einmalcodes, nicht erlaubte Origins oder einen nicht implementierten Datensatz. Die Anwendung sollte solche Fälle getrennt behandeln und die vom Endpunkt zurückgelieferte Fehlermeldung protokollieren, ohne geheime Inhalte mitzuschreiben. Ein erfolgreicher Request bestätigt nur diesen Verarbeitungsschritt, nicht automatisch einen im Anschluss angelagerten E-Mail-, Zahlungs- oder SSO-Erfolg. Dies ist für „POST /api/auth/forgot-password“ unmittelbar relevant. Die technische Prüfung dieser Seite ist zwingend zu sich auf die Registry unter `app/frontend/src/content/api-reference/` und die zugehörigen Backend-Routen stützen. Live-Test-Vermerke dürfen nur das behaupten, was tatsächlich geprüft wurde. Ein Negativtest oder eine Code-Analogie ist kein vollständiger Erfolgsnachweis. Für POST /api/auth/forgot-password — API-Referenz ist daher klar zwischen dokumentierter Struktur, automatisiertem Test und sicher beobachtetem Live-Verhalten zu unterscheiden.

Auth & Absicherung

Keine Authentifizierung erforderlich

Idempotent: Ja

Parameter

email(body, string, erforderlich)E-Mail-Adresse des Kontos

Beispiel-Request

{"email":"user@example.com"}

Beispiel-Response

{"ok":true}

Fehlercodes

400 VALIDATION_ERRORE-Mail-Feld fehlt oder ist leer.

Live-Test-Nachweis

Erfolg (200, neutrale Antwort unabhängig davon ob der Account existiert) und Negativfall (400 bei fehlendem Feld) live verifiziert.

Authentifizierung