Your VM's login credentials — the username and password shown under Service Info / View Details in the client portal — are also readable over the customer API. This is the same pair you see on the portal's Service Info panel, returned to you programmatically so an agent or script can connect without a human copy-pasting from the dashboard. See The customer API and MCP for how to get a key, and Connecting to Your Server for how to use the credentials once you have them.

The endpoint

A single call returns the decrypted login pair for one of your servers, addressed by its service ID:

curl -s https://blesta.sovereignhybridcompute.com/user-api/v2/vm/{serviceId}/credentials \
  -H "Authorization: Bearer shc_live_..."

The response is the standard envelope with a data object holding two string fields:

{
  "data": {
    "user": "root",
    "password": "the-decrypted-vm-password"
  }
}

• user — the VM login username from Service Info.
• password — the VM login password from Service Info, returned decrypted, exactly as the portal's Service Info view shows it. If a field was never set it comes back as an empty string rather than being omitted.

Over MCP the same data is exposed as the getVirtualMachineCredentials tool. The always-current shape lives in the live API reference.

Who can read it, and for which servers

• Scope: this is a credential-read, treated exactly like any other VM read — a read-scoped key (or higher) can call it, the same as GET /vm/{serviceId}/detail. It is read-only: it returns your password but never changes it, and it spends nothing. There is no separate confirmation step — it is a single call, at parity with the portal's Service Info view. (Managing keys, your password, or 2FA still stays password-only.)
• Ownership: the call is scoped to the client that owns the API key. You can only read credentials for a service that belongs to your own account. Ask for a service ID you don't own — or one that isn't a VM — and the API answers 404 VM not found, exactly like every other /vm/{serviceId} endpoint. We don't confirm or deny the existence of other customers' services.

Windows caveat

For Windows VMs the password returned here may not be the password the machine actually boots with. Windows runs its own first-boot setup (OOBE), and the credential injected at provisioning time can be superseded before the desktop is ready — so the value from this endpoint can be stale or invalid for a Windows server until that first-boot/cloud-init password step is fixed. If a Windows login is rejected, use the web console to set or confirm the password (see Managing your VM), or reinstall. Linux VMs are unaffected: the returned password matches what's on the machine.

Keep it safe

This endpoint hands back a real secret. Treat the response like any other credential: don't log it, don't echo it into a shared transcript, and prefer SSH keys over passwords where you can — you can inject a key at any time from the portal or the API (see SSH keys and access). If a password is ever exposed, reinstall or rotate it.