API-Schlüssel und Zugriffsrechte verwalten
Ein API-Schlüssel gibt einer externen Anwendung Zugriff auf Ihr edoobox-Konto. Seine Möglichkeiten entsprechen dem zugewiesenen Recht. Behandeln Sie ihn deshalb mit derselben Sorgfalt wie einen Admin-Zugang und erstellen Sie für jeden Zweck einen eigenen Schlüssel.
Ein neuer Zugang besteht aus Public Key und Secret Key. Der Secret Key wird nach dem Erstellen nur einmal angezeigt. Ohne sicher gespeichertes Secret kann derselbe Zugang später nicht vollständig rekonstruiert werden.
Zweck und Recht vorab festlegen
Dokumentieren Sie vor der Erstellung Anwendung, verantwortliche Person, Umgebung und benötigte Aktionen. Ein reiner Export benötigt kein Schreibrecht; eine WordPress-Einbindung oder Zapier-Automation sollte ihr dafür vorgesehenes Recht erhalten.
Die V2-Oberfläche bietet vorhandene individuelle Rechte und, falls noch nicht eingerichtet, vorbereitete Optionen für Leserecht, WordPress Recht und Zapier Recht. Bei einer solchen Auswahl legt edoobox das passende Recht an und verknüpft es mit dem Schlüssel.
Schlüssel erstellen
Öffnen Sie als Superadmin Einstellungen → API Zugangsverwaltung und wählen Sie Schlüssel hinzufügen.
Entscheiden Sie, ob der Zugang sofort Aktiv sein soll, und wählen Sie genau ein Recht.
Bestätigen Sie mit Hinzufügen. Kopieren Sie Public und Secret Key unmittelbar in den vorgesehenen Secret- oder Passwortmanager.
Schliessen Sie den Dialog erst, nachdem die sichere Ablage geprüft wurde. Senden Sie das Secret nicht unverschlüsselt per E-Mail oder Chat.
Bestehende Zugänge kontrollieren
Die API-Tabelle erlaubt, den Public Key zu kopieren und einen Zugang aktiv oder inaktiv zu schalten. Wenn das ursprünglich zugewiesene Recht gelöscht wurde, zeigt die Tabelle keine Rechte mehr. Dieser Schlüssel ist dann nicht korrekt einsatzbereit; weisen Sie nicht blind ein anderes Recht zu, ohne den Integrationszweck zu prüfen.
Führen Sie mindestens quartalsweise eine Kontrolle durch:
Ist die Anwendung noch im Einsatz und ist eine verantwortliche Person bekannt?
Passt das Recht weiterhin zum tatsächlichen Datenzugriff?
Gehört der Schlüssel zur richtigen Umgebung, zum Beispiel Test oder Produktion?
Gibt es veraltete, doppelte oder nicht dokumentierte Zugänge?
Schlüssel ohne unnötigen Ausfall erneuern
Erstellen Sie einen neuen Schlüssel mit demselben minimalen Recht und speichern Sie das neue Secret sicher.
Hinterlegen Sie Public und Secret Key im Zielsystem und testen Sie eine lesende beziehungsweise ungefährliche Anfrage.
Beobachten Sie den produktiven Ablauf. Deaktivieren Sie erst danach den alten Schlüssel.
Aktualisieren Sie Ihre interne Dokumentation mit Datum und verantwortlicher Person.
Fehler systematisch eingrenzen
| Symptom | Prüfung |
|---|---|
| Authentifizierung schlägt fehl | Public und Secret Key, vertauschte Werte, Leerzeichen, Umgebung und aktiven Status prüfen. |
| Zugriff verweigert | Zugewiesenes Recht und benötigte Ressource vergleichen; keine Rechte mehr beachten. |
| Lesen funktioniert, Schreiben nicht | Leserecht ist absichtlich begrenzt. Nur bei fachlichem Bedarf ein engeres Schreibrecht erstellen. |
| Integration stoppt nach Wechsel | Prüfen, ob beide neuen Schlüsselwerte im Zielsystem gespeichert und dessen Prozesse neu geladen wurden. |
Anwendungsbeispiele
Anwendungsbeispiel: Read-only Reporting
Ein internes Dashboard liest Angebote und Buchungen, verändert aber keine Daten. Dafür erhält es einen eigenen aktiven Schlüssel mit Leserecht. Der Schlüssel ist getrennt von WordPress und Zapier dokumentiert und kann unabhängig deaktiviert werden.
Anwendungsbeispiel: WordPress und Zapier trennen
Die Website verwendet einen Schlüssel mit WordPress-Recht, eine Rechnungsautomation einen zweiten mit Zapier-Recht. Fällt die Automation weg, kann ihr Schlüssel deaktiviert werden, ohne die Website-Einbindung zu unterbrechen.
Anwendungsbeispiel: Verdacht auf offengelegtes Secret
Ein Secret war versehentlich in einer internen Notiz sichtbar. Das Team deaktiviert sofort den betroffenen Zugang, erstellt einen Ersatzschlüssel und hinterlegt ihn sicher im Zielsystem. Danach testet es die Verbindung und prüft fehlgeschlagene oder ausstehende Verarbeitungsschritte, bevor diese kontrolliert wiederholt werden. Das alte Secret wird nicht weiterverwendet.
Rechteprofil mit dem Betrieb abstimmen
Für die Erstellung benötigen Sie Superadmin-Rechte und Zugriff auf Einstellungen → API Zugangsverwaltung. Der Dialog enthält Status und Rechteauswahl. Ein beschreibender Schlüsselname ist dort kein eigenes Eingabefeld; führen Sie Zweck, Verantwortlichkeit und Umgebung deshalb in Ihrer internen Zugangsliste anhand des Public Key.
Für vorhandene Schlüssel zeigt die Übersicht Status, Public Key und das verknüpfte Rechteprofil. Über den Link zum Rechteprofil prüfen Sie dessen Inhalt. Sollen Umfang oder Zweck wesentlich geändert werden, erstellen Sie einen separaten Zugang mit dem vorgesehenen Recht und führen Sie die Umstellung kontrolliert durch.