POST/api/auth/sso/exchange

Sista steget i en SSO-inloggning (SAML/OIDC): byter den engångskod som utfärdats av callbacken mot en vanlig session-JWT.

Sidan ”POST /api/auth/sso/exchange — API-referens” behandlar det funktionsområde som anges i URL:en. Det befintliga innehållet kompletteras med det faktiska förloppet, förutsättningarna och de kända begränsningarna. Zentor har inget API-nyckelsystem för utvecklare. För dashboarden används session-JWT:er med tolv timmars giltighetstid och refresh-tokens med sju dagars giltighetstid; TOTP och SSO är valfria. Widget-embed-tokens visas en enda gång i klartext och är bundna till tillåtna origins. Dokumentationen för `POST /api/auth/sso/exchange` ska läsas som en bindande teknisk beskrivning av just denna endpoint. Avgörande är metod, sökväg, autentisering, obligatoriska fält, möjliga fel och frågan om ett nytt anrop utlöser samma effekt. Detta hjälpavsnitt https://zentor-app.de/hilfe/api-referenz/auth/auth.sso_exchange får därför inte innehålla några allmänna reklampåståenden, utan endast begripliga integrationssteg som följer på det, samt styrkta svarsexempel. För ett anrop till `/api/auth/sso/exchange` byggs begäran upp enligt registret. Offentliga routes kräver ingen allmän API-nyckel för utvecklare, eftersom Zentor inte erbjuder något sådant nyckelsystem. Skyddade widget-routes använder däremot den embed-token som visas en enda gång samt en origin-kontroll. HTTP-status och JSON-innehåll måste utvärderas tillsammans; ett `ok`-fält ensamt ersätter inte felhantering. Vid test av `POST /api/auth/sso/exchange` ska anonymiserade värden användas. Verkliga kunddata, produktiva UUID:er, sessionstokens och konkreta tidsstämplar hör inte hemma i offentliga exempel. Den kända plattformsövergripande gränsen är 2.000 begäranden inom 15 minuter; en avvikande enskild gräns är inte belagd. Icke-idempotenta POST-anrop får inte upprepas blint efter ett oklart nätverksavbrott. Typiska integrationsfel för denna route beror på saknade obligatoriska parametrar, felaktiga datatyper, utgångna engångskoder, icke tillåtna origins eller en post som inte är implementerad. Applikationen bör hantera sådana fall separat och logga det felmeddelande som endpointen returnerar, utan att skriva med hemligt innehåll. En lyckad begäran bekräftar endast detta bearbetningssteg, inte automatiskt en därpå följande e-post-, betalnings- eller SSO-framgång. Detta är direkt relevant för ”POST /api/auth/sso/exchange”. Den tekniska granskningen av denna sida ska nödvändigtvis stödja sig på registret under `app/frontend/src/content/api-reference/` och tillhörande backend-routes. Anteckningar om live-test får bara påstå det som faktiskt har prövats. Ett negativt test eller en kodanalogi är inget fullständigt bevis på framgång. För POST /api/auth/sso/exchange — API-referens måste man därför tydligt skilja mellan dokumenterad struktur, automatiserat test och säkert observerat live-beteende.

{"code":"<Engångskod från SSO-callback-omdirigeringen>"}

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