All three modules authenticate against the OVH API with a three-part token: an application key, an application secret and a consumer key. Mint one at the token-creation page of the endpoint you sell on:

Tokens are endpoint-specific. A token minted on ovh-eu is invalid on ovh-ca or ovh-us, and the US endpoint is a separate legal entity with its own account and credentials. Legacy kimsufi-*/soyoustart-* accounts can manage servers only — new Eco orders go through the main ovh-eu/ovh-ca endpoints.

Rights per module

Grant GET, POST, PUT and DELETE on:

Set the token validity to unlimited — the modules use it for daily automation.

Subsidiaries (VPS & Dedicated)

The OVH Subsidiary on the module row tells OVH which regional catalog and legal entity to order from. It must match the endpoint or the row will not save:

Use the subsidiary your OVH account was registered under (it appears on your OVH invoices). The Public Cloud module has no subsidiary — it works inside an existing project instead.

Adding the credentials in Blesta

On the module's Manage page add a row — OVH Account (VPS/Dedicated: name, endpoint, subsidiary and the three keys) or Cloud Project (Public Cloud: name, endpoint, the three keys and the project ID). The module calls the OVH API (GET /me) before saving, so a row that saves is a row that works; if saving fails, re-check the endpoint/subsidiary pairing and the token rights. The application secret and consumer key are stored encrypted.

Heads-up: auto-ordering (VPS and Dedicated) pays with the OVH account's preferred payment method. Set one in the OVH Control Panel under Billing > Payment methods before selling, or orders will fail at checkout.