POST/api/auth/sso/exchange

Poslední krok SSO přihlášení (SAML/OIDC): vymění jednorázový kód vydaný callbackem za běžné session JWT.

Stránka „POST /api/auth/sso/exchange — API-Referenz“ se zabývá funkční oblastí označenou v URL. Stávající obsah je doplněn o skutečný průběh, předpoklady a známé limity. Zentor nemá systém vývojářských API klíčů. Pro dashboard se používají session JWT s dobou platnosti dvanáct hodin a refresh tokeny s dobou platnosti sedm dní; TOTP a SSO jsou volitelné. Widget embed tokeny se zobrazují jednorázově v čistém textu a jsou vázány na povolené origins. Dokumentace k `POST /api/auth/sso/exchange` má být závazně čtena jako technický popis tohoto konkrétního endpointu. Rozhodující jsou metoda, cesta, autentizace, povinná pole, možné chyby a otázka, zda opětovné volání vyvolá stejný efekt. Tato část nápovědy https://zentor-app.de/hilfe/api-referenz/auth/auth.sso_exchange proto nesmí obsahovat žádná obecná reklamní tvrzení, ale pouze následně proveditelné integrační kroky a doložené příklady odpovědí. Pro volání `/api/auth/sso/exchange` se požadavek sestaví podle registru. Veřejné trasy nevyžadují obecný vývojářský API klíč, protože Zentor žádný takový systém klíčů nenabízí. Chráněné trasy widgetů naopak používají jednorázově zobrazený embed token a kontrolu origin. Stav HTTP a obsah JSON je třeba vyhodnotit společně; samotné pole `ok` nenahrazuje zpracování chyb. Při testování `POST /api/auth/sso/exchange` je třeba použít anonymizované hodnoty. Skutečná zákaznická data, produkční UUID, session tokeny a konkrétní časová razítka nepatří do veřejných příkladů. Známý celoplatformní limit je 2.000 požadavků během 15 minut; odlišný individuální limit není doložen. Neidempotentní volání POST se nesmí po nejasném přerušení sítě slepě opakovat. Typické integrační chyby pro tuto trasu vznikají kvůli chybějícím povinným parametrům, špatným datovým typům, prošlým jednorázovým kódům, nepovoleným origins nebo neimplementované datové sadě. Aplikace by měla takové případy zpracovávat odděleně a protokolovat chybovou zprávu vrácenou koncovým bodem, aniž by zapisovala tajný obsah. Úspěšný požadavek potvrzuje pouze tento krok zpracování, nikoli automaticky následný úspěch e-mailu, platby nebo SSO. To je přímo relevantní pro „POST /api/auth/sso/exchange“. Technická kontrola této stránky se musí nutně opírat o registr v `app/frontend/src/content/api-reference/` a související backendové trasy. Poznámky o živém testu smí tvrdit pouze to, co bylo skutečně prověřeno. Negativní test nebo kódová analogie nejsou úplným důkazem úspěchu. U POST /api/auth/sso/exchange — API reference je proto nutné jasně rozlišovat mezi dokumentovanou strukturou, automatizovaným testem a spolehlivě pozorovaným živým chováním.

{"code":"Jednorázový kód z SSO callback redirectu"}

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