POST/api/auth/sso/exchange

Sidste trin i et SSO-login (SAML/OIDC): bytter den af callbacket udstedte engangskode mod et regulært session-JWT.

Siden „POST /api/auth/sso/exchange — API-reference“ behandler det funktionsområde, der er angivet i URL'en. Det eksisterende indhold suppleres med den faktiske proces, forudsætningerne og de kendte begrænsninger. Zentor har ikke et system med udvikler-API-nøgler. Til dashboardet bruges 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/sso/exchange` 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. Denne hjælpesektion https://zentor-app.de/hilfe/api-referenz/auth/auth.sso_exchange må derfor ikke indeholde generelle reklameudsagn, men kun verificerbare integrationstrin og dokumenterede svareksempler. Til et kald af `/api/auth/sso/exchange` opbygges anmodningen i overensstemmelse med registret. 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 engangs viste embed-token og en oprindelseskontrol. HTTP-status og JSON-indholdet skal vurderes sammen; et `ok`-felt alene erstatter ikke fejlhåndtering. Ved test af `POST /api/auth/sso/exchange` skal der anvendes anonymiserede værdier. Reelle kundedata, produktive UUID'er, sessionstokens og konkrete tidsstempler hører ikke hjemme i offentlige eksempler. Den kendte platformsdækkende grænseværdi er 2.000 anmodninger inden for 15 minutter; et afvigende individuelt limit 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, som endepunktet returnerer, uden at skrive hemmeligt indhold med. 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/sso/exchange“. 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-test-notater må kun hævde det, der faktisk er blevet kontrolleret. En negativ test eller en kodeanalogi er ikke et fuldstændigt bevis på succes. For POST /api/auth/sso/exchange — API-referencen skal der derfor klart skelnes mellem dokumenteret struktur, automatiseret test og sikkert observeret live-adfærd.

{"code":"<Engangskode fra SSO-Callback-Redirect>"}

{"ok":true,"token":"<JWT>","refreshToken":"<Refresh-Token>"}