POST/api/auth/sso/exchange

Последний шаг входа через SSO (SAML/OIDC): обменивает выданный callback-ом одноразовый код на обычный сессионный JWT.

Страница «POST /api/auth/sso/exchange — справочник API» описывает функциональную область, обозначенную URL. Существующий контент дополнен фактическим процессом, требованиями и известными ограничениями. Zentor не имеет системы ключей разработчика API. Для дашборда используются сессионные JWT с временем жизни двенадцать часов и токены обновления (refresh tokens) с временем жизни семь дней; TOTP и SSO являются опциональными. Токены встраивания виджетов отображаются один раз в открытом виде и привязаны к разрешенным источникам. Документация для `POST /api/auth/sso/exchange` должна рассматриваться как обязательное техническое описание данного конкретного эндпоинта. Критически важны метод, путь, аутентификация, обязательные поля, возможные ошибки и вопрос о том, вызывает ли повторный вызов тот же эффект. Следовательно, этот раздел помощи https://zentor-app.de/hilfe/api-referenz/auth/auth.sso_exchange не должен содержать общих рекламных заявлений, а лишь выполняемые шаги интеграции и подтвержденные примеры ответов. Для вызова `/api/auth/sso/exchange` запрос формируется в соответствии с реестром. Публичные маршруты не требуют общего ключа разработчика API, поскольку Zentor не предоставляет такой системы ключей. Защищенные маршруты виджетов, напротив, используют отображаемый один раз токен встраивания и проверку источника. Статус HTTP и содержимое JSON должны оцениваться совместно; одно лишь поле `ok` не заменяет обработку ошибок. При тестировании `POST /api/auth/sso/exchange` следует использовать анонимизированные значения. Реальные данные клиентов, производственные UUID, токены сессий и конкретные временные метки не должны попадать в публичные примеры. Известный общеплатформенный лимит составляет 2.000 запросов в течение 15 минут; отдельный лимит для конкретного случая не подтвержден. Неидемпотентные POST-вызовы не следует повторять слепо после неясного сбоя сети. Типичные ошибки интеграции для этого маршрута возникают из-за отсутствия обязательных параметров, неверных типов данных, истекших одноразовых кодов, недопустимых источников или отсутствия реализованной записи. Приложение должно обрабатывать такие случаи отдельно и регистрировать сообщение об ошибке, возвращаемое эндпоинтом, не записывая при этом конфиденциальные данные. Успешный запрос подтверждает лишь этот этап обработки, а не автоматически последующий успех отправки email, платежа или 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>"}