API-Authentifizierung
Wie Dashboard-Login und Widget-Embed-Token funktionieren — kein Developer-API-Key-System.
Die Seite „API-Authentifizierung in Zentor ohne API-Key“ behandelt den in der URL bezeichneten Funktionsbereich. Der vorhandene Inhalt wird um den tatsächlichen Ablauf, die Voraussetzungen und die bekannten Grenzen ergänzt. Zentor besitzt kein Entwickler-API-Key-System. Für das Dashboard werden Session-JWTs mit zwölf Stunden Laufzeit und Refresh-Tokens mit sieben Tagen Laufzeit verwendet; TOTP und SSO sind optional. Widget-Embed-Tokens werden einmalig im Klartext angezeigt und sind an zugelassene Origins gebunden.
Zentor bietet kein allgemeines Entwickler-API-Key-System. Für das Dashboard werden Session-JWTs mit zwölf Stunden Laufzeit und Refresh-Tokens mit sieben Tagen Laufzeit genutzt. Optional stehen TOTP und SSO zur Verfügung.
Das Widget eingesetzt einen Embed-Token, der nur einmal im Klartext angezeigt wird. Zusätzlich wird die Origin geprüft. Token und Domainfreigabe gehören daher zusammen; ein gültiger Token von einer nicht zugelassenen Origin reicht nicht aus.
Session-JWTs und Widget-Tokens dürfen nicht in Quellcode-Repositories, öffentliche Logs oder Dokumentationsbeispiele gelangen. Nach Ablauf oder Widerruf soll verbindlich die Anwendung den vorgesehenen Erneuerungs- beziehungsweise Anmeldeprozess verwenden.
Interne Dashboard- und Master-Admin-Routen sind nicht Teil einer öffentlichen Entwickler-API. Eine erfolgreiche Anmeldung berechtigt nur im Rahmen der Rolle und des aktiven Tenants. Integrationen dürfen keine internen Endpunkte als stabile öffentliche Schnittstelle behandeln.
Für die Seite „API-Authentifizierung in Zentor ohne API-Key“ gilt damit: Der im Vorfeld vorhandene Kurztext wird zu einer belastbaren Anleitung erweitert, ohne Produktfunktionen außerhalb des bestätigten Produktstands zu versprechen. Maßgeblich bleiben die verifizierten Faktenquellen und die sichtbare Zuständigkeit zwischen Tenant und Zentor. Im Fall von Abweichungen sollten immer genau diese URL, der betroffene Mandant und der beobachtete Schritt genannt werden.
Bei der Arbeit mit „api-authentifizierung“ sollte jeder Schritt zunächst mit einem kontrollierten Testfall geprüft werden. Entscheidend ist, dass die sichtbare Einstellung, der tatsächliche Systemstatus und das erwartete Ergebnis zusammenpassen. Bei Abweichungen helfen eine genaue Uhrzeit, der betroffene Mandant, der verwendete Kanal und die unveränderte Fehlermeldung bei der Analyse. Zugangsdaten, Tokens und personenbezogene Inhalte dürfen dabei nicht in Screenshots oder Supporttexte übernommen werden.