obhut Dokumentation
obhut betreibt autoritatives DNS, Zertifikate, TLS-Terminierung, eine WAF und Hosting für statische
Websites in einer Plattform. Diese Seite dokumentiert seine API, die auch das Dashboard, die
obhut CLI und ihr MCP-Server nutzen.
Hinweis
Die Referenzen gibt es nur auf Englisch: Sie entstehen aus dem Code, und ihre technischen Namen sind englisch.
Ihre erste Anfrage
Sie brauchen ein obhut-Konto und ein API-Token. Erstellen Sie das Token im Dashboard auf der Seite API-Tokens. Das Dashboard zeigt sein Geheimnis nur einmal, bewahren Sie es also sicher auf.
Senden Sie das Token im Header Authorization. Diese Anfrage antwortet mit dem Aufrufer, hier dem
Token selbst:
curl https://api.obhut.io/v1/me \
-H "Authorization: Bearer $OBHUT_TOKEN"Hinweis
Die Seite jeder Operation nennt die Berechtigung, die sie braucht. Geben Sie einem Token nur die Berechtigungen, die seine Arbeit braucht.
Welches Release diese Seite beschreibt
Das Release, das die API betreibt, baut auch diese Seite, aus demselben Code. Die Fußzeile jeder Seite nennt dieses Release.
Was die Edge an Ihren Origin weiterleitet
edged, die Edge, die Ihre Hostnamen bedient, leitet ein WebSocket-Upgrade an Ihren Origin
weiter, wenn es wie in RFC 6455 beschrieben beginnt: ein GET mit Sec-WebSocket-Version: 13
und einem 16-Byte-Sec-WebSocket-Key. Sie gibt die Verbindung weiter, sobald das 101 Ihres
Origins das Sec-WebSocket-Accept dieses Schlüssels trägt, und antwortet sonst mit 502. Jedes
andere Upgrade (h2c, jedes andere Protokoll) und jeder HTTP2-Settings-Header erhalten 400,
und nichts erreicht Ihren Origin: Nach einem Upgrade würde die Verbindung Anfragen an der
Firewall, den Ratenlimits und Access vorbei tragen (seit 2026-11-02). Ein Connection-Header darf
nur close, keep-alive, te, transfer-encoding, upgrade und proxy-connection nennen;
jedes andere Token erhält 400, denn die Edge würde einen Header dieses Namens wie Content-Type
entfernen, bevor Ihr Origin die Anfrage liest. Trailer einer Anfrage leitet sie nicht weiter.