API-authenticatie
Hoe dashboardlogin en widget-embedtoken werken — geen API-sleutelsysteem voor ontwikkelaars.
De pagina "API-authenticatie in Zentor zonder API-sleutel" behandelt het in de URL aangeduide functionaliteitsgebied. De bestaande inhoud wordt aangevuld met het daadwerkelijke verloop, de vereisten en de bekende beperkingen. Zentor beschikt niet over een API-sleutelsysteem voor ontwikkelaars. Voor het dashboard worden sessie-JWT's met een looptijd van twaalf uur en refresh-tokens met een looptijd van zeven dagen gebruikt; TOTP en SSO zijn optioneel. Widget-embed-tokens worden eenmalig in platte tekst weergegeven en zijn gebonden aan toegestane origins.
Zentor biedt geen algemeen API-sleutelsysteem voor ontwikkelaars. Voor het dashboard worden sessie-JWT's met een looptijd van twaalf uur en refresh-tokens met een looptijd van zeven dagen gebruikt. TOTP en SSO zijn optioneel beschikbaar.
De widget gebruikt een embed-token dat slechts één keer in platte tekst wordt weergegeven. Daarnaast wordt de origin gecontroleerd. Token en domeinvrijgave horen daarom bij elkaar; een geldig token van een niet-toegelaten origin is niet voldoende.
Sessie-JWT's en widget-tokens mogen niet terechtkomen in broncode-repositories, openbare logs of documentatievoorbeelden. Na verloop of intrekking dient de applicatie verplicht het voorziene vernieuwings- of inlogproces te gebruiken.
Interne dashboard- en master-admin-routes maken geen deel uit van een openbare ontwikkelaars-API. Een succesvolle inlog geeft alleen rechten binnen het kader van de rol en de actieve tenant. Integraties mogen interne eindpunten niet behandelen als een stabiele openbare interface.
Voor de pagina "API-authenticatie in Zentor zonder API-sleutel" geldt dus: de eerder aanwezige korte tekst wordt uitgebreid tot een betrouwbare handleiding, zonder productfuncties buiten de bevestigde productstand te beloven. De geverifieerde feitenbronnen en de zichtbare verantwoordelijkheid tussen tenant en Zentor blijven bepalend. Bij afwijkingen moeten altijd precies deze URL, de betrokken tenant en de waargenomen stap worden genoemd.
Bij het werken met "api-authentifizierung" moet elke stap eerst worden getest met een gecontroleerde testcase. Belangrijk is dat de zichtbare instelling, de daadwerkelijke systeemstatus en het verwachte resultaat overeenkomen. Bij afwijkingen helpen een nauwkeurig tijdstip, de betrokken tenant, het gebruikte kanaal en de ongewijzigde foutmelding bij de analyse. Inloggegevens, tokens en persoonsgegevens mogen niet worden overgenomen in screenshots of supportteksten.