POST/api/auth/sso/exchange

Останній крок входу SSO (SAML/OIDC): обмін одноразовим кодом, виданим через Callback, на звичайний сесійний JWT.

Сторінка «POST /api/auth/sso/exchange — довідник API» описує функціональну область, зазначену в URL. Наявний вміст доповнено фактичним процесом, передумовами та відомими обмеженнями. Zentor не має системи API-ключів для розробників. Для панелі керування використовуються сесійні JWT із терміном дії дванадцять годин і refresh-токени з терміном дії сім днів; TOTP і SSO є необов'язковими. Widget-Embed-Tokens показуються у відкритому вигляді лише один раз і прив'язані до дозволених Origins. Документацію до `POST /api/auth/sso/exchange` слід обов'язково читати як технічний опис саме цієї кінцевої точки. Вирішальними є метод, шлях, автентифікація, обов'язкові поля, можливі помилки та питання, чи спричиняє повторний виклик той самий ефект. Тому цей розділ довідки https://zentor-app.de/hilfe/api-referenz/auth/auth.sso_exchange не повинен містити загальних рекламних тверджень, а лише зрозумілі подальші кроки інтеграції та підтверджені приклади відповідей. Для виклику `/api/auth/sso/exchange` запит формується відповідно до реєстру (Registry). Публічним маршрутам не потрібен загальний API-ключ розробника, оскільки Zentor не пропонує такої системи ключів. Натомість захищені маршрути віджета використовують одноразово показаний Embed-Token і перевірку Origin. HTTP-статус і JSON-вміст потрібно оцінювати разом; саме лише поле `ok` не замінює обробку помилок. Під час тестування `POST /api/auth/sso/exchange` слід використовувати анонімізовані значення. Реальним даним клієнтів, робочим UUID, сесійним токенам і конкретним часовим міткам не місце в публічних прикладах. Відоме загальноплатформне обмеження становить 2 000 запитів протягом 15 хвилин; окреме індивідуальне обмеження не підтверджено. Неідемпотентні POST-виклики не можна наосліп повторювати після нечіткого обриву мережевого з'єднання. Типові помилки інтеграції для цього маршруту виникають через відсутні обов'язкові параметри, неправильні типи даних, прострочені одноразові коди, недозволені Origins або нереалізований набір даних. Застосунок має обробляти такі випадки окремо та протоколювати повернуте кінцевою точкою повідомлення про помилку, не записуючи секретного вмісту. Успішний запит підтверджує лише цей крок обробки, а не автоматично успіх подальшого надсилання ел. листа, платежу чи SSO. Це безпосередньо стосується «POST /api/auth/sso/exchange». Технічна перевірка цієї сторінки обов'язково має спиратися на реєстр у `app/frontend/src/content/api-reference/` і відповідні бекенд-маршрути. Примітки про живі тести можуть стверджувати лише те, що було фактично перевірено. Негативний тест або аналогія з кодом не є повним доказом успіху. Тому для POST /api/auth/sso/exchange — довідник API потрібно чітко розрізняти задокументовану структуру, автоматизований тест і надійно спостережувану поведінку в робочому режимі.

{"code":"<одноразовий код із переспрямування SSO-Callback>"}

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