Fast jedes CDN hat eine API. Die meisten haben allerdings nur einen Ausschnitt davon: die Endpunkte, die irgendwann jemand geschrieben hat, für die Einstellungen, bei denen jemand Automatisierung für plausibel hielt. Der Rest liegt hinter einem Dashboard. Und genau dort endet dann die Automatisierung.
Mit dem Umbau der Middleware im Kern von smoxy gilt das hier nicht mehr.
Der Hub ist nur ein weiterer API-Client
Entscheidend ist nicht die Zahl neuer Endpunkte. Entscheidend ist, dass es nur noch einen Weg in die Plattform gibt und der Hub ihn genauso nutzt wie alle anderen.
Wird im Dashboard eine WAF-Regel umgeschaltet, ein Hostname ergänzt oder ein Origin getauscht, schickt der Hub dieselbe Anfrage an dieselbe öffentliche API, für die auch jedes Token gilt. Kein privater Kanal, keine internen Sonderrouten, keine Einstellung, die es in der Oberfläche gibt, in der API aber namenlos bleibt.
Aus dieser einen Änderung folgt alles Weitere.
Was der Hub kann, kann die API
Die öffentliche API umfasst inzwischen 167 Operationen in 42 Ressourcengruppen und deckt das Produkt damit in seiner Breite ab, nicht nur die bequemen Teile:
- Auslieferung - Zonen, Hostnamen, Origin-Server, Load Balancer, Cache leeren, Weiterleitungen und Redirect Maps
- Sicherheit - WAF-Regeln, Access Rules, Security-Szenarien, Blocklisten und Allowlists je Zone, IP-Listen, Basic-Auth-Benutzer, IP-Lookup
- Konfiguration - Rewrite Rules, Conditional Rules, Eigene Seiten, verwaltete URL-Parameter
- Infrastruktur - Domains, DNS-Einträge, Zertifikate samt SANs
- Auswertung - CDN- und Traffic-Logs, Audit-Logs, Zonen-KPIs
- Organisation - Mitglieder, Einladungen, API-Tokens, Abrechnung
Was sich im Hub konfigurieren lässt, lässt sich auch mit einem Token und einem curl-Aufruf konfigurieren. Genau darum geht es.
Gebaut für Systeme, die ohnehin schon laufen
Kaum ein Team wünscht sich noch ein Control Panel. Gewünscht ist, dass smoxy sich in die vorhandene Systemlandschaft einfügt, und die passt selten sauber auf die Oberfläche eines Anbieters.
Am deutlichsten wird das bei der IP-Filterung. In vielen Teams werden Allow- und Blocklisten längst an anderer Stelle gepflegt: in einem internen Risiko-Service, einem SIEM, einer Fraud-Pipeline oder schlicht in einer Tabelle, der die Sicherheitsverantwortlichen tatsächlich vertrauen. Bisher hieß das: jemand pflegt dieselben Listen ein zweites Mal von Hand im Browser. Heute genügt ein geplanter Job, der das führende System gegen IP-Listen und Zonen-Blocklisten abgleicht. Daran denken muss am Freitagnachmittag niemand mehr.
Das lässt sich beliebig weiterdenken. Pro Pull Request eine Zone anlegen und beim Merge wieder abräumen. Zertifikate aus derselben Pipeline erneuern, die auch den Rest der Infrastruktur erneuert. Cache-Invalidierung beim Veröffentlichen direkt aus dem CMS auslösen statt von Hand. Traffic-Kennzahlen in das Dashboard holen, in das das Team ohnehin schaut, statt noch eines zu öffnen.
Auch die Tokens sind dafür gemacht: begrenzt auf einzelne Organisationen, bei Bedarf auf Lesezugriff beschränkt und mit Ablaufdatum versehen. Ein Metrik-Exporter braucht keine Berechtigung, mit der sich eine Zone löschen lässt.
Warum das die Entwicklung beschleunigt
Was nach einem internen Detail klingt, ist keines.
Weil der Hub selbst API-Client ist, kann die API dem Produkt nicht mehr hinterherhinken. Es gibt keine separate Anbindung mehr zu planen und keinen Rückstand an Endpunkten, die "auch noch" nachgezogen werden müssten. Eine Einstellung erscheint gemeinsam mit ihrem Endpunkt, weil sie ihr Endpunkt ist.
Damit ist der langsamste und fehleranfälligste Schritt aus dem Release-Prozess verschwunden. Änderungen am Frontend gehen jetzt in kleinen Schritten raus, an den meisten Tagen der Woche, statt auf ein Paket zu warten, das groß genug ist, um den Abstimmungsaufwand zu rechtfertigen. Kleine Änderungen lassen sich leichter prüfen, leichter zurücknehmen und müssen deutlich seltener zurückgenommen werden.
Sichtbar wird das als stetiger Strom aus Korrekturen und Verbesserungen, und als API, die am Tag einer Neuerung vollständig ist statt ein Quartal später.
Erste Schritte
Unter Konto → API-Tokens ein Token anlegen, dann:
curl -H "X-API-TOKEN: <token>" https://api.smoxy.eu/api/zonesDenselben Aufruf macht der Hub, um die Zonenliste darzustellen.
- Die API-Referenz dokumentiert jede Operation mit Request-Schema, Beispielantworten und fertigen Code-Snippets, und erlaubt Testaufrufe direkt im Browser.
- API-Tokens beschreibt Geltungsbereich, Lesezugriff und Rotation.
- Das maschinenlesbare Schema liegt unter openapi.json und dient als Grundlage für einen eigenen Client in beliebiger Sprache.
- Wer mit KI-Assistenten arbeitet, findet im smoxy MCP-Server dieselbe API hinter einer dialogorientierten Schnittstelle.
Damit lässt sich endlich die Integration bauen, die von Anfang an gemeint war. Das Dashboard bleibt selbstverständlich bestehen. Es ist nur nicht mehr der einzige Weg hinein.
