Authentication
Requests are authorized with a token in the Authorization header. The first token is issued outside this API, in your ZennoHosting account; from then on it travels with every call.
The rules
- Get a token before touching projects, VMs, networks, backups or public IPs.
Send the
Authorizationheader on every request.The value must have the form
Bearer <token>.- Keep tokens out of source code — pass them through configuration or a secret store.
Where /tokens fits in
The reference includes /tokens, but that is token management from inside an already-authorized
session, not a way to get access from nothing. If you have no access yet, issue the first token in your ZennoHosting
account. The number of tokens is capped by the accessTokens quota in GET /limits.
Your first request
Start with something that changes nothing. Listing projects is the best check: it confirms the base URL, the header and the token itself in one go.
curl --request GET \
--url 'https://api.zennohosting.com/v1/projects' \
--header 'Authorization: Bearer <token>' \
--header 'Accept: application/json'Base URL and Accept
The version is part of the base URL — https://api.zennohosting.com/v1 — so a documented path such as
/projects is called as {base URL}/projects. Every response body is JSON, so
Accept is optional; the examples send Accept: application/json to keep it explicit.
What to build into the client
- Handling for token expiry and replacement.
- One base URL per environment and one place that assembles headers.
- Scoped tokens wherever automation does not need full access.
- A named owner for token rotation in long-lived pipelines.
Telling an access problem apart
A missing Bearer prefix, an expired token and a malformed Authorization header all look the
same early on — and look a lot like a wrong base URL. The distinguishing signal is a 401 response. Check
the header shape and the token's validity before looking for the cause in the request body.