API-Tokens

Alles, was du im Dashboard tun kannst, geht auch über die REST-API: Vorfälle anlegen, Komponenten schalten, Wartungen planen, Metriken senden. Dafür brauchst du ein Token.

Anlegen

Unter Konto → API-Tokens → Neues Token. Du vergibst:

• Name — wofür es ist. „GitHub Actions", „Grafana", „Statusmonitor". Du wirst dich in einem Jahr fragen, welches welches war.
• Berechtigungen — Nur lesen oder Lesen und schreiben.
• Ablaufdatum — optional. Das Token funktioniert bis zum Ende dieses Tages.

Das Token wird einmal angezeigt. Danach nicht mehr — wir speichern nur dessen Prüfsumme. Verlierst du es, legst du ein neues an.

Nur lesen

Im Starter-Tarif ist die API immer nur lesend, auch mit einem Token für Lesen und schreiben; schreiben kannst du ab Basic.

Ein Token mit Nur lesen kann alles abfragen und nichts verändern. Jeder schreibende Zugriff wird mit einem Fehler abgewiesen, egal was dein Tarif erlaubt.

Persönliche Daten und Zugangsdaten sieht ein solches Token nur verdeckt: E-Mail-Adressen und Telefonnummern von Abonnenten und Monitor-Empfängern (z. B. j••••@example.com, ••••••••••567) und Webhook-Adressen (nur der Host). Ein Token für Lesen und schreiben sieht sie vollständig.

Nimm es überall, wo etwas nur schauen muss: ein Dashboard, ein Statusmonitor, ein Skript, das vor dem Deployment prüft, ob gerade eine Störung läuft. Wenn so ein Token abhandenkommt, hat der Finder deine Statusseite gelesen — mehr nicht.

Bindung an den Workspace

Ein Token gehört zu dem Workspace, in dem du es angelegt hast. Gehörst du zu mehreren, funktioniert es nur für diesen einen. Das ist Absicht: ein Token für den Kunden-Workspace soll nicht versehentlich den internen mitändern können.

Praktischer Nebeneffekt: Du musst keinen Workspace-Header mitschicken. Das Token weiß, wohin es gehört.

Deshalb siehst du unter API-Tokens nur die Tokens des Workspaces, in dem du gerade bist. Ausnahme: Tokens aus der Zeit, bevor es diese Bindung gab, gelten für alle deine Workspaces und stehen überall in der Liste, markiert mit „alle deine Workspaces“. Ersetz sie bei Gelegenheit durch gebundene.

Zugriff auf Statusseiten

Ein Token darf nie mehr als die Person, der es gehört. Ist dein Zugriff auf einzelne Statusseiten beschränkt, sieht das Token Seiten ohne Zugriff nicht (404), und auf Seiten mit Nur lesen wird jeder schreibende Aufruf mit 403 abgewiesen. GET /api/v1/statuspages listet nur die Seiten, die du sehen darfst.

Verwenden

curl https://statuswerk.eu/api/v1/statuspage \
  -H "Authorization: Bearer DEIN_TOKEN"

Hat dein Workspace mehrere Statusseiten, wählst du die gewünschte mit einem zusätzlichen Header:

X-Statuspage-Id: <uuid>

Ohne den Header geht die Anfrage an die älteste Statusseite des Workspaces.

Die API antwortet immer auf Englisch: Fehlermeldungen, Status-Bezeichnungen, Blätter-Links. Was du selbst schickst (Titel, Texte), erscheint so, wie du es schreibst. Auf der Statusseite und in den Benachrichtigungen gilt deren eingestellte Sprache.

Zurückziehen

In der Liste steht bei jedem Token, wann es zuletzt benutzt wurde. Nie benutzt nach ein paar Wochen ist ein gutes Zeichen dafür, dass es weg kann. Zurückziehen wirkt sofort und ist nicht umkehrbar.

Tokens, die vor der Einführung der Berechtigungen angelegt wurden, haben vollen Zugriff und laufen nicht ab. Sie funktionieren weiter — aber wenn du sie ohnehin anfasst, leg sie lieber neu an.

Wird dein Benutzerkonto gesperrt, löschen wir alle deine Tokens sofort; API und MCP-Server antworten dann mit 401. Nach einer Entsperrung brauchst du neue Tokens.

Tempolimit

Die API nimmt 120 Anfragen pro Minute und Token. Darüber antwortet sie mit 429, bis die Minute um ist. Aufrufe, die etwas testen, prüfen oder eine Bestätigung verschicken, sind auf 10 pro Minute begrenzt. Für ein Monitoring, das im Minutentakt fragt, ist das reichlich; für einen Import in einer Schleife kann es eng werden — dann bündle die Anfragen.

Was es alles gibt

Die vollständige Referenz mit allen Endpunkten, Feldern und Beispielen steht unter /docs/api. Dort kannst du Aufrufe auch direkt ausprobieren.