Das Sicherheitskonzept der API v2: Berechtigungsstufen, Gated Routes, Bestätigungstoken und Rate-Limits im Überblick.

  • Least Privilege per Token
  • Bestätigungstoken für zerstörerische Aktionen
  • Ressourcen-Pinning und Rate-Limits

Auf einen Blick

Die Prepaid-Hoster API v2 ist mehrschichtig abgesichert. Jede Schicht lässt sich pro Token einzeln setzen, sodass ein Key immer nur genau das kann, was dein Anwendungsfall braucht.

  • Berechtigungsstufe: Lesezugriff oder Schreibzugriff.
  • Gated Routes: Freigabe einzelner Routen oder ganzer Routengruppen per Wildcard.
  • Ressourcen-Pinning: Bindung einer Route an konkrete Hosting- oder Domain-IDs.
  • Bestätigungstoken: Zusätzliche Freigabe für kritische Aktionen mit Daten-, Kosten- oder Verfügbarkeitsfolgen.
  • Rate-Limits: Feste Anfragekontingente pro Zeitfenster, mit separatem Kontingent für DNS.
  • MCP-Zugriff: Standardmäßig deaktiviert, nur auf Anfrage freischaltbar.

Wie du einen Token anlegst und die Grundoptionen setzt, steht im Einstiegsartikel Wie erhalte ich einen API Key?. Dieser Beitrag erklärt, wie die Absicherung dahinter funktioniert.

Hinweis: Die API befindet sich aktuell noch in der Entwicklung. Einzelne Mechanismen können sich noch ändern. Die hier beschriebenen Grundprinzipien bleiben bestehen.

Grundprinzip: so wenig Rechte wie möglich

Ein API-Token ist ein Zugang zu deinem Account. Kompromittiert jemand einen Token, kann er alles tun, was der Token darf. Deshalb gilt für jeden Token dieselbe Faustregel: Vergib nur die Rechte, die der konkrete Anwendungsfall wirklich braucht.

Ein Monitoring-Skript braucht keinen Schreibzugriff. Ein Backup-Skript für einen einzelnen Server braucht keinen Zugriff auf alle deine Dienste. Je enger du einen Token schneidest, desto kleiner ist der Schaden, falls er verloren geht.

Berechtigungsstufe: Lesen oder Schreiben

Jeder Token hat eine von zwei Stufen:

  • Nur Lesezugriff: Der Token darf Daten ausschließlich abfragen. Alle schreibenden Routen werden abgewiesen.
  • Mit Schreibrechten: Der Token darf zusätzlich Daten anlegen, ändern und löschen.

Diese Stufe ist die grobe Weiche. Alles Weitere schränkt den Zugriff innerhalb der gewählten Stufe weiter ein.

Gated Routes und Ressourcen-Pinning

Standardmäßig darf ein Token alle Routen ansprechen, die seine Berechtigungsstufe erlaubt. Mit Gated Routes drehst du das um: Ist die Funktion aktiv, darf der Token nur noch die Routen nutzen, die du explizit freigibst. Jeder andere Aufruf wird mit HTTP 403 abgewiesen, inklusive des kanonischen Routennamens in der Fehlermeldung.

Freigeben kannst du auf zwei Arten, die sich kombinieren lassen:

  • Wildcards: vps.status.index gibt genau eine Route frei. vps.* gibt alle VPS-Routen frei. domains.records.* gibt alle DNS-Record-Routen frei.
  • Ressourcen-Pinning: Über Hosting IDs und Domain IDs bindest du eine freigegebene Route an konkrete Ressourcen. Der Token nutzt die Route dann nur für genau diese IDs.

So baust du dir zum Beispiel einen Token, der vps.* darf, aber ausschließlich auf einem einzigen Server.

Bestätigungstoken für kritische Aktionen

Manche Aktionen haben Folgen, die sich nicht einfach zurücknehmen lassen. Sie überschreiben Daten, lösen Kosten aus oder greifen in die Verfügbarkeit eines Servers ein. Für diese Routen reicht ein gültiger API-Token allein nicht aus. Sie verlangen zusätzlich ein Bestätigungstoken.

Aktuell brauchen diese Aktionen ein Bestätigungstoken:

  • Ein Backup zurückspielen, auf denselben oder auf einen anderen Server
  • Einen Snapshot zurückspielen
  • Das Betriebssystem neu installieren (Rebuild)
  • Die Ausstattung eines Servers ändern (CPU, RAM, Storage)
  • Den Rescue-Modus aktivieren
  • Ein ISO einbinden und den zugehörigen Boot-Vorgang starten
  • Einen neuen Server bestellen
  • Ein Hosting sofort kündigen

Der Ablauf ist immer gleich:

  1. Du rufst eine dieser Routen ohne Bestätigungstoken auf. Die API führt die Aktion nicht aus, sondern weist darauf hin, dass eine Bestätigung nötig ist.
  2. Du erzeugst ein Bestätigungstoken für genau diese Aktion. Das geht über das Webinterface oder über die API selbst.
  3. Du wiederholst die Anfrage und sendest das Bestätigungstoken mit. Erst jetzt wird die Aktion ausgeführt.

Das Bestätigungstoken ist kurzlebig und an die konkrete Aktion gebunden. Der Sinn dahinter: Selbst ein Token mit vollen Schreibrechten kann nicht versehentlich oder durch einen Fehler im automatisierten Ablauf eine solche Aktion auslösen. Es braucht immer einen zweiten, bewussten Schritt.

Das ist besonders für automatisiert laufende Keys wertvoll. Ein Cronjob oder ein agentischer Client kann seine Routine abarbeiten, kommt aber an einer kritischen Aktion nicht ohne den zusätzlichen Bestätigungsschritt vorbei.

P.S.: Bei Domains werden bei zerstörerischen Aktionen ein automatisches und nicht löschbares Snapshot deiner Records angelegt, welches du jederzeit (ebenfalls per API-Aufruf) jederzeit zurückspielen kannst.

Human in the loop (Coming soon)

Die nächste Ausbaustufe des Bestätigungssystems ist Human in the loop. Aktivierst du sie für einen Token, wird die Bestätigung aus dem technischen Ablauf herausgelöst und an einen Menschen übergeben.

Statt dass der Client sich das Bestätigungstoken selbst generiert, geht bei einer kritischen Aktion eine Nachricht mit einem Bestätigungslink an dich, zum Beispiel per E-Mail. Erst wenn du den Link öffnest und die Aktion freigibst, wird sie ausgeführt. Lehnst du ab oder reagierst du nicht, verfällt die Anfrage. Das ist besonders für agentische Aktionen von Vorteil.

Der entscheidende Punkt: Der Bestätigungslink geht nie an den API-Client zurück. Ein automatisierter Ablauf kann die Freigabe also nicht selbst erteilen. Die Kontrolle über kritische Aktionen bleibt beim Kontoinhaber, auch wenn ein Token vollautomatisch läuft oder in falsche Hände gerät.

Rate-Limits

Jeder Token unterliegt einem Anfragekontingent pro Zeitfenster. Das schützt die Plattform vor Überlastung und begrenzt den Schaden durch einen außer Kontrolle geratenen oder missbrauchten Token.

  • Das allgemeine Kontingent liegt aktuell bei 150 Anfragen pro 60 Sekunden.
  • DNS-Endpunkte haben ein zusätzliches, separates Kontingent, damit DNS-Änderungen die allgemeine Quote nicht aufbrauchen.
  • Das Kontingent skaliert mit der Anzahl deiner aktiven Dienste.

Jede Antwort enthält die Header X-RateLimit-Limit und X-RateLimit-Remaining, an denen du deinen aktuellen Stand ablesen kannst. Dein exaktes Kontingent und die Sekunden bis zum Reset fragst du jederzeit über die Quota-Route deines Tokens ab.

MCP-Zugriff ist opt-in

Tokens lassen sich optional für die Nutzung mit MCP-Servern (Model Context Protocol) freischalten, etwa um die API an einen KI-Assistenten anzubinden. Diese Fähigkeit ist bewusst standardmäßig nicht verfügbar und wird pro Account manuell freigeschaltet.

Der Grund: Ein KI-Assistent, der im Namen deines Accounts handelt, verschiebt einen Teil der Verantwortung. Vor der Freischaltung klären wir dich über die Konsequenzen auf und holen deine Zustimmung ein. In Kombination mit Schreibzugriff greift hier zusätzlich das Bestätigungstoken-System als Schutzschicht. Wenn du MCP nutzen möchtest, melde dich beim Support.

Fähigkeiten eines Tokens einsehen

Du musst nicht raten, was ein Token darf. Die API liefert dir die vollständigen Fähigkeiten deines Tokens zurück:

{
  "description": "Backup-Skript",
  "token_create_date": "2026-08-14T09:00:59.000000Z",
  "token_expiration_date": null,
  "token_last_used_date": "2026-08-21T06:31:43.000000Z",
  "capabilities": {
    "mcp_access": false,
    "write_access": true,
    "routes": "*",
    "expanded_routes": [],
    "confirmation_tokens": {
      "human_in_the_loop": false,
      "human_in_the_loop_config": null
    }
  }
}

Die Felder im Einzelnen:

  • write_access: Ob der Token schreiben darf oder nur liest.
  • routes: Die freigegebenen Routen. * bedeutet alle, andernfalls stehen hier deine Gated Routes.
  • expanded_routes: Deine Wildcards in aufgelöster Form, also die einzelnen Routen, die eine Regel wie vps.* tatsächlich abdeckt.
  • mcp_access: Ob der Token für MCP freigeschaltet ist.
  • confirmation_tokens.human_in_the_loop: Ob für diesen Token die Bestätigung per Mensch aktiv ist.
  • token_last_used_date: Wann der Token zuletzt genutzt wurde. Praktisch, um verwaiste Tokens zu erkennen.

Token-Lebenszyklus und Widerruf

Ein Token bleibt gültig, bis du ihn widerrufst oder ein gesetztes Ablaufdatum erreicht ist. Zwei Empfehlungen für den Alltag:

  • Prüfe über token_last_used_date regelmäßig, ob deine Tokens noch aktiv genutzt werden. Einen nicht verwendeten Token solltest du widerrufen.
  • Nutze getrennte Tokens für getrennte Aufgaben. So kannst du einen einzelnen kompromittierten oder nicht mehr benötigten Token widerrufen, ohne alle anderen Integrationen zu stören. Es gibt kein Token-Limit.

Einen Token deaktivierst du sofort, indem du in den API-Token Details den Haken bei Token widerrufen setzt und speicherst. Ein widerrufener Token wird ab der nächsten Anfrage abgewiesen.

Nachvollziehbarkeit (Coming soon)

Demnächst kannst du Aktionen und Logs deiner Tokens direkt im Webinterface einsehen. Du siehst dann, welche Aktion wann über welchen Token ausgeführt wurde. Das erleichtert die Fehlersuche und macht auffällige Zugriffe schnell sichtbar.

Noch Fragen?

Technische Fragen zur API beantworten dir unsere Entwickler direkt in unserem Discord. Stell deine Frage im Entwickler-Channel und pinge das Dev-Team an.