POST/api/auth/forgot-password

Utløser sending av en e-post for tilbakestilling av passord, dersom det finnes en konto med denne adressen. Svarer bevisst alltid likt (det er ikke mulig å slutte seg til om kontoen finnes).

Siden «POST /api/auth/forgot-password — API-referanse» omhandler funksjonsområdet som angis i URL-en. Det eksisterende innholdet utvides med den faktiske prosessen, forutsetningene og de kjente begrensningene. Zentor har ikke noe system for utvikler-API-nøkler. For dashbordet brukes sesjons-JWT-er med tolv timers gyldighet og refresh-tokens med sju dagers gyldighet; TOTP og SSO er valgfrie. Widget-embed-tokens vises bare én gang i klartekst og er knyttet til godkjente origins. Dokumentasjonen for `POST /api/auth/forgot-password` skal leses som en bindende teknisk beskrivelse av akkurat dette endepunktet. Avgjørende er metode, sti, autentisering, obligatoriske felt, mulige feil og spørsmålet om et nytt kall utløser samme effekt. Denne hjelpeseksjonen https://zentor-app.de/hilfe/api-referenz/auth/auth.forgot_password skal derfor ikke inneholde generelle markedsføringspåstander, men bare etterprøvbare integrasjonstrinn og dokumenterte svareksempler. For et kall til `/api/auth/forgot-password` bygges forespørselen opp i samsvar med registeret. Offentlige ruter krever ingen generell utvikler-API-nøkkel, fordi Zentor ikke tilbyr et slikt nøkkelsystem. Beskyttede widget-ruter bruker derimot embed-tokenet som vises én gang, og en origin-kontroll. HTTP-statusen og JSON-innholdet må vurderes samlet; et `ok`-felt alene erstatter ikke feilhåndtering. Ved testing av `POST /api/auth/forgot-password` skal det brukes anonymiserte verdier. Reelle kundedata, produktive UUID-er, sesjonstokens og konkrete tidsstempler hører ikke hjemme i offentlige eksempler. Den kjente plattformomfattende grensen er 2 000 forespørsler innen 15 minutter; en avvikende enkeltgrense er ikke dokumentert. Ikke-idempotente POST-kall må ikke gjentas blindt etter et uklart nettverksbrudd. Typiske integrasjonsfeil for denne ruten skyldes manglende obligatoriske parametere, feil datatyper, utløpte engangskoder, ikke-tillatte origins eller en datapost som ikke er implementert. Applikasjonen bør håndtere slike tilfeller hver for seg og logge feilmeldingen som endepunktet returnerer, uten å logge hemmelig innhold. En vellykket forespørsel bekrefter bare dette behandlingstrinnet, ikke automatisk at en etterfølgende e-post, betaling eller SSO-innlogging har lyktes. Dette er direkte relevant for «POST /api/auth/forgot-password». Den tekniske kontrollen av denne siden må nødvendigvis støtte seg på registeret under `app/frontend/src/content/api-reference/` og de tilhørende backend-rutene. Live-test-merknader skal bare hevde det som faktisk er kontrollert. En negativtest eller en kodeanalogi er ikke et fullstendig bevis på suksess. For POST /api/auth/forgot-password — API-referanse må det derfor skilles tydelig mellom dokumentert struktur, automatisert test og sikkert observert live-atferd.

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

{"ok":true}