Conventions

What holds across every operation: where to send a call, how the two API versions coexist, what a failed call returns, and the limits that apply.

Agent setup

Bases

Three regions, two versions, the same shapes. A call goes to the region your account lives in; this hub shows the EU bases because that is the region it is served from.

EUhttps://api.eu.ovhcloud.com/1.0https://api.eu.ovhcloud.com/v2

CAhttps://api.ca.ovhcloud.com/1.0https://api.ca.ovhcloud.com/v2

UShttps://api.us.ovhcloud.com/1.0https://api.us.ovhcloud.com/v2

Everything is JSON over HTTPS. A path segment in braces is a value you supply — {serviceName} in /hosting/web/{serviceName}.

v1 and v2

Both versions are live and neither replaces the other. A product may expose part of its surface under /1.0 and a newer part under /v2.

This hub merges the two per section so you read one list rather than two. Where the same path and method exist in both, the v2 definition is the one shown, and the operation carries a v2 marker. The version also decides the base of its sample.

Formats

Dates and times follow RFC 3339 on every operation, in UTC or with their offset — 2026-10-06T14:30:00Z, 2026-10-06T16:30:00+02:00. In the reference, a field's format is shown next to its type (date-time) rather than repeated in its description.

Lifecycle

Each operation carries its lifecycle stage — Production, Beta, Alpha or Deprecated — and is authenticated unless it is marked Public. A deprecated operation keeps its page, dimmed, for as long as it answers, with the date it was deprecated, the date it is removed and, when there is one, the route that replaces it.

Not documented by the API: pagination, filtering, ordering

The documents declare each operation's parameters, but no convention shared between them: there is no declared pagination scheme, no common filter or sort parameter, and no stated rule for list responses. What exists is per-operation, and this page will not generalise from a sample.

HTTP methods

Four verbs, one badge each — the same badge the sidebar and every operation header carry. This is the legend.

GETReads a resource or lists a collection. Changes nothing.

POSTCreates a resource, or runs an action the resource declares.

PUTReplaces a resource with the payload it is given. PATCH carries the same badge and changes only the fields it names.

DELETERemoves a resource, or asks for its termination.

Errors

Responses follow HTTP semantics, and the reference colours them by family:

2xxThe call succeeded. The body is the documented payload.

4xxThe call was rejected: a missing or invalid token, a value the API refused, a resource that does not exist.

5xxThe call failed on the API side.

Not documented by the API: the error responses themselves

The aggregated documents declare success responses and almost nothing else. Measured on 26 September 2026 over five sections — Account, Web Hosting, IP, Dedicated Servers and Public Cloud Instances — 729 operations declare a 200, and exactly one declares anything else (400, 403, 404, 409, 500, 501).

So this hub cannot list, per operation, which errors it can return, what an error body looks like, or which error codes carry a meaning of their own. Until the schemas carry them, treat the status code as the only contract.

Not documented by the API: rate limits

No rate limit, quota or throttling header is declared anywhere in the documents. This page states none rather than repeating a figure from elsewhere. The limits that do apply, and the headers that announce them, have to come from the API team.