POST/api/auth/forgot-password
Nis dërgimin e një emaili për rivendosjen e fjalëkalimit, nëse ekziston një llogari me këtë adresë. Përgjigjet gjithmonë në të njëjtën mënyrë (nuk mund të nxirret përfundim për ekzistencën e llogarisë).
Faqja „POST /api/auth/forgot-password — Referenca e API-së“ trajton fushën funksionale të përcaktuar në URL. Përmbajtja ekzistuese plotësohet me rrjedhën reale, parakushtet dhe kufizimet e njohura. Zentor nuk ka sistem çelësash API për zhvilluesit. Për Dashboard përdoren Session-JWT me vlefshmëri dymbëdhjetë orë dhe Refresh-Token me vlefshmëri shtatë ditë; TOTP dhe SSO janë opsionale. Widget-Embed-Token shfaqen vetëm një herë në tekst të qartë dhe janë të lidhur me Origins të lejuara. Dokumentacioni për `POST /api/auth/forgot-password` duhet lexuar në mënyrë të detyrueshme si përshkrim teknik i kësaj pike fundore konkrete. Vendimtare janë metoda, shtegu, autentifikimi, fushat e detyrueshme, gabimet e mundshme dhe pyetja nëse një thirrje e përsëritur shkakton të njëjtin efekt. Prandaj ky seksion ndihme https://zentor-app.de/hilfe/api-referenz/auth/auth.forgot_password nuk duhet të përmbajë deklarata të përgjithshme reklamuese, por vetëm hapa integrimi të kuptueshëm dhe shembuj përgjigjesh të dokumentuar. Për një thirrje të `/api/auth/forgot-password` kërkesa ndërtohet sipas Registry-t. Shtigjet publike nuk kërkojnë çelës të përgjithshëm API për zhvilluesit, sepse Zentor nuk ofron një sistem të tillë çelësash. Shtigjet e mbrojtura të widget-it përdorin në vend të kësaj Embed-Token-in e shfaqur një herë dhe një kontroll të Origin. Statusi HTTP dhe përmbajtja JSON duhet të vlerësohen së bashku; vetëm një fushë `ok` nuk zëvendëson trajtimin e gabimeve. Gjatë testimit të `POST /api/auth/forgot-password` duhet të përdoren vlera të anonimizuara. Të dhënat reale të klientëve, UUID-të produktive, tokenët e sesionit dhe vulat kohore konkrete nuk duhet të përfshihen në shembujt publikë. Kufiri i njohur për gjithë platformën është 2.000 kërkesa brenda 15 minutave; një kufi individual i ndryshëm nuk është i dokumentuar. Thirrjet POST jo-idempotente nuk duhet të përsëriten verbërisht pas një ndërprerjeje të paqartë të rrjetit. Gabimet tipike të integrimit për këtë shteg lindin nga parametrat e detyrueshëm që mungojnë, llojet e gabuara të të dhënave, kodet njëpërdorimshe të skaduara, Origins të palejuara ose një regjistër i pazbatuar. Aplikacioni duhet t’i trajtojë këto raste veçmas dhe të regjistrojë mesazhin e gabimit të kthyer nga pika fundore, pa regjistruar përmbajtje sekrete. Një kërkesë e suksesshme konfirmon vetëm këtë hap përpunimi, jo automatikisht suksesin e një hapi pasues të emailit, pagesës ose SSO-së. Kjo është drejtpërdrejt e rëndësishme për „POST /api/auth/forgot-password“. Kontrolli teknik i kësaj faqeje duhet të mbështetet detyrimisht te Registry në `app/frontend/src/content/api-reference/` dhe te shtigjet përkatëse të backend-it. Shënimet e testeve live mund të pohojnë vetëm atë që është kontrolluar realisht. Një test negativ ose një analogji kodi nuk është provë e plotë suksesi. Prandaj për POST /api/auth/forgot-password — Referenca e API-së duhet dalluar qartë ndërmjet strukturës së dokumentuar, testit të automatizuar dhe sjelljes live të vëzhguar me siguri.
Autentifikimi dhe siguria
Nuk kërkohet autentifikim
Idempotent: Po
Parametrat
email(body, string, i detyrueshëm)— Adresa e emailit të llogarisëShembull request-i
{"email":"user@example.com"}Shembull response-i
{"ok":true}Kodet e gabimeve
400 VALIDATION_ERROR — Fusha e emailit mungon ose është e zbrazët.Prova e testit live
Verifikim në kohë reale i suksesit (200, përgjigje neutrale pavarësisht ekzistencës së llogarisë) dhe të rastit negativ (400 nëse fusha mungon).