API-Аутентифікація
Як працюють вхід у Dashboard та токени вбудовування Widget — без системи ключів API для розробників.
Сторінка «Автентифікація API в Zentor без API-ключа» описує функціональну область, зазначену в URL. Наявний вміст доповнено фактичним процесом, передумовами та відомими обмеженнями. Zentor не має системи API-ключів для розробників. Для панелі керування використовуються сесійні JWT із терміном дії дванадцять годин і refresh-токени з терміном дії сім днів; TOTP і SSO є необов'язковими. Widget-Embed-Tokens показуються у відкритому вигляді лише один раз і прив'язані до дозволених Origins.
Zentor не пропонує загальної системи API-ключів для розробників. Для панелі керування використовуються сесійні JWT із терміном дії дванадцять годин і refresh-токени з терміном дії сім днів. Додатково доступні TOTP і SSO.
Віджет використовує Embed-Token, який показується у відкритому вигляді лише один раз. Додатково перевіряється Origin. Тому токен і дозвіл домену пов'язані між собою; дійсного токена з недозволеного Origin недостатньо.
Сесійні JWT і токени віджета не повинні потрапляти до репозиторіїв вихідного коду, публічних журналів чи прикладів документації. Після закінчення терміну дії або відкликання застосунок обов'язково має використовувати передбачений процес оновлення або входу.
Внутрішні маршрути панелі керування та Master Admin не є частиною публічного API для розробників. Успішний вхід надає права лише в межах ролі та активного орендаря. Інтеграції не повинні розглядати внутрішні кінцеві точки як стабільний публічний інтерфейс.
Отже, для сторінки «Автентифікація API в Zentor без API-ключа» діє таке: наявний раніше короткий текст розширено до надійної інструкції без обіцянок функцій поза підтвердженим станом продукту. Визначальними залишаються перевірені джерела фактів і видимий розподіл відповідальності між орендарем і Zentor. У разі розбіжностей завжди слід вказувати саме цю URL-адресу, відповідного клієнта та спостережуваний крок.
Під час роботи з «api-authentifizierung» кожен крок спершу слід перевіряти на контрольованому тестовому випадку. Вирішальним є те, щоб видиме налаштування, фактичний стан системи та очікуваний результат збігалися. У разі розбіжностей для аналізу допомагають точний час, відповідний клієнт, використаний канал і незмінене повідомлення про помилку. Облікові дані, токени та персональні дані при цьому не можна переносити на знімки екрана чи в тексти для підтримки.