POST/api/auth/forgot-password

Udløser afsendelsen af en e-mail til nulstilling af adgangskode, såfremt der findes en konto med denne adresse. Svarer bevidst altid ens (ingen mulighed for at udlede, om kontoen findes).

Siden „POST /api/auth/forgot-password — API-Referenz“ behandler det i URL'en angivne funktionsområde. Det eksisterende indhold udvides med det faktiske forløb, forudsætningerne og de kendte begrænsninger. Zentor har ikke et system med udvikler-API-nøgler. Til dashboardet anvendes session-JWT'er med en levetid på tolv timer og refresh-tokens med en levetid på syv dage; TOTP og SSO er valgfrie. Widget-embed-tokens vises én gang i klartekst og er bundet til godkendte origins. Dokumentationen for `POST /api/auth/forgot-password` skal læses som en bindende teknisk beskrivelse af dette konkrete endpoint. Det afgørende er metode, sti, autentificering, obligatoriske felter, mulige fejl og spørgsmålet om, hvorvidt et nyt kald udløser samme effekt. Dette hjælpeafsnit https://zentor-app.de/hilfe/api-referenz/auth/auth.forgot_password må derfor ikke indeholde generelle reklameudsagn, men kun efterprøvbare integrationstrin og dokumenterede svareksempler. For et kald til `/api/auth/forgot-password` opbygges anmodningen i overensstemmelse med Registry. Offentlige ruter kræver ingen generel udvikler-API-nøgle, fordi Zentor ikke tilbyder et sådant nøglesystem. Beskyttede widget-ruter bruger derimod den engangsviste embed-token og en origin-kontrol. HTTP-statusen og JSON-indholdet skal evalueres sammen; et `ok`-felt alene erstatter ikke fejlhåndtering. Ved test af `POST /api/auth/forgot-password` skal der anvendes anonymiserede værdier. Reelle kundedata, produktions-UUID'er, sessionstokens og konkrete tidsstempler hører ikke til i offentlige eksempler. Den kendte platformsdækkende grænse er 2.000 anmodninger inden for 15 minutter; et afvigende individuelt loft er ikke dokumenteret. Ikke-idempotente POST-kald må ikke blindt gentages efter et uklart netværksafbrud. Typiske integrationsfejl for denne rute opstår på grund af manglende obligatoriske parametre, forkerte datatyper, udløbne engangskoder, ikke tilladte origins eller et ikke-implementeret datasæt. Applikationen bør håndtere sådanne tilfælde separat og logge den fejlmeddelelse, der returneres fra endepunktet, uden at logge hemmeligt indhold. En vellykket anmodning bekræfter kun dette behandlingstrin, ikke automatisk en efterfølgende tilknyttet e-mail-, betalings- eller SSO-succes. Dette er umiddelbart relevant for „POST /api/auth/forgot-password“. Den tekniske gennemgang af denne side skal nødvendigvis støtte sig til registret under `app/frontend/src/content/api-reference/` og de tilhørende backend-ruter. Live-testnotater må kun hævde det, der faktisk er blevet testet. En negativ test eller en kodeanalogi er ikke et fuldstændigt bevis på succes. For POST /api/auth/forgot-password — API-referencen skal derfor klart adskille mellem dokumenteret struktur, automatiseret test og sikkert observeret live-adfærd.

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

{"ok":true}