obhut documentation

obhut operates authoritative DNS, certificates, TLS termination, a WAF and hosting for static websites in one platform. This site documents its API, which the dashboard, the obhut CLI and its MCP server use too.

API referenceEvery operation, with its permission, its fields and an example request and response.Error codesThe stable codes of the API's errors, and what each one means.

Your first request

You need an obhut account and an API token. Create the token on the dashboard's API tokens page. The dashboard shows its secret once, so keep the secret in a safe place.

Send the token in the Authorization header. This request answers with the caller, here the token itself:

curl

curl https://api.obhut.io/v1/me \
  -H "Authorization: Bearer $OBHUT_TOKEN"

Note

Each operation's page names the permission that the operation needs. Give a token only the permissions that its work needs.

Which release this describes

The release that runs the API also builds this site, from the same code. The footer of each page names that release.

What the edge forwards to your origin

edged, the edge that serves your hostnames, forwards a WebSocket upgrade to your origin when it opens as RFC 6455 says: a GET with Sec-WebSocket-Version: 13 and a 16-byte Sec-WebSocket-Key. It relays the connection once your origin's 101 carries that key's Sec-WebSocket-Accept, and answers 502 otherwise. Every other upgrade (h2c, any other protocol) and any HTTP2-Settings header get 400, and nothing reaches your origin: after an upgrade the connection would carry requests past the firewall, the rate limits and Access (since 2026-11-02). A Connection header may name only close, keep-alive, te, transfer-encoding, upgrade and proxy-connection; any other token gets 400, since the edge would remove a header of that name, such as Content-Type, before your origin reads the request. Request trailers are not forwarded.