Summary
In hPanel I can fully manage a second account's resources, because its owner granted me access.
The API cannot reach any of it: a token issued by my account only ever returns resources my own
account owns. Delegated access exists in the console but has no equivalent in the API.
What I observe
With a valid API token:
GET /api/vps/v1/virtual-machines returns only VPS instances my own account owns. A VPS I
administer every day through hPanel — granted to me via access sharing — is not in the list.GET /api/billing/v1/subscriptions likewise shows only my own subscriptions.- There is no endpoint that lists the accounts a token holder can act on.
- No endpoint accepts an account /
client_id parameter or header to target a different account.
/api/agency-hosting/v1/* is not a substitute: it covers the Agency plan product and returns
{"data": [], "meta": {"total": 0}} for a regular account that merely has shared access.
I went through every endpoint family in the published API surface (hosting, vps, dns, domains,
billing, mail, reach, ecommerce, horizons, agency-hosting, wordpress) and found no way to express
"act on the account I was granted access to".
Request
Make delegated access reachable from the API. A minimal shape that would solve it:
- An endpoint listing accounts the token holder can act on, with the permission level granted —
e.g. GET /api/account/v1/accessible-accounts.
- An account selector accepted by existing endpoints — a header such as
X-Hostinger-Account: <id>, or an optional query parameter — with the API enforcing the same
permissions the console already enforces.
Scoping tokens to a subset of granted accounts would be a welcome addition, but is not required
to unblock the basic case.
Why it matters
Teams that centralise infrastructure under a shared operations account can use hPanel but cannot
automate anything. The only workaround today is asking the owning account to issue its own API
token and passing that credential to whoever needs it — which is precisely what access sharing
exists to avoid. The current design pushes users toward sharing credentials instead of sharing
access.
Summary
In hPanel I can fully manage a second account's resources, because its owner granted me access.
The API cannot reach any of it: a token issued by my account only ever returns resources my own
account owns. Delegated access exists in the console but has no equivalent in the API.
What I observe
With a valid API token:
GET /api/vps/v1/virtual-machinesreturns only VPS instances my own account owns. A VPS Iadminister every day through hPanel — granted to me via access sharing — is not in the list.
GET /api/billing/v1/subscriptionslikewise shows only my own subscriptions.client_idparameter or header to target a different account./api/agency-hosting/v1/*is not a substitute: it covers the Agency plan product and returns{"data": [], "meta": {"total": 0}}for a regular account that merely has shared access.I went through every endpoint family in the published API surface (hosting, vps, dns, domains,
billing, mail, reach, ecommerce, horizons, agency-hosting, wordpress) and found no way to express
"act on the account I was granted access to".
Request
Make delegated access reachable from the API. A minimal shape that would solve it:
e.g.
GET /api/account/v1/accessible-accounts.X-Hostinger-Account: <id>, or an optional query parameter — with the API enforcing the samepermissions the console already enforces.
Scoping tokens to a subset of granted accounts would be a welcome addition, but is not required
to unblock the basic case.
Why it matters
Teams that centralise infrastructure under a shared operations account can use hPanel but cannot
automate anything. The only workaround today is asking the owning account to issue its own API
token and passing that credential to whoever needs it — which is precisely what access sharing
exists to avoid. The current design pushes users toward sharing credentials instead of sharing
access.