Exchange is excluded from this API/CLI release. Any historical Exchange API or CLI example in this guide is unavailable; native portal behavior is outside this exclusion. See current release scope.

Hosting packages and immutable Plesk plans

A platform administrator can manage Hosting packages through Hosting → Packages or the company-scoped administration API. Administration requires the appropriate admin:read / admin:write scope, a current internal administrator, a recent passkey verification, and enabled administration/security features. An ordinary company owner or service integration cannot use these operations.

What changes

Creating or editing a package creates a separate immutable Plesk service plan on each currently configured Hosting server. The portal verifies the provider plan's exact ID, GUID, external reference, resource limits and spam-filter permission before publishing it for new orders. The commercial price and billing period become effective together with the confirmed plan revisions.

Changes apply to future orders. Existing subscriptions retain their quota and commercial agreement. An already paid task retains its exact approved historical plan, even after the package name or latest revision changes. Old plan revisions remain available for that readback; they are not silently changed or deleted. Before the first conversion of a legacy package, outstanding legacy provisioning must be completed or reconciled.

This workflow deliberately does not issue Plesk service-plan/set: that operation can change unlocked existing subscriptions. A separate explicit migration of existing quotas and contracts is not part of this package update. Retirement removes a package from the offer and retains the local Product, existing subscriptions and provider plans.

API workflow

All paths below are relative to /api/v1/accounts/{account}. Discover the current capabilities and read the current OpenAPI contract before a write.

Send Idempotency-Key for writes and the current If-Match for update, retirement and actions. A metadata dry-run validates local configuration and current authorization without creating a Product, journal entry or provider plan. Prices are decimal EUR strings excluding tax. Billing periods are months. Resource values are integers: -1 means unlimited; disk space, traffic and mailbox quota use bytes, and the other fields use counts.

{
  "name": "Hosting Plus",
  "sell_price": "14.95",
  "exceed_price": "0.00",
  "period_months": 12,
  "overuse": "block",
  "spamfilter": false,
  "limits": {
    "maxSites": 1,
    "maxSubdomains": 10,
    "maxDomainAliases": 10,
    "diskSpace": 1073741824,
    "traffic": -1,
    "maxWebUsers": 0,
    "maxSubFTPUsers": 0,
    "maxDatabases": 5,
    "maxMailboxes": 0,
    "mailboxQuota": 0,
    "maxMaillists": 0,
    "maxWebApps": 5
  }
}

The supported overuse policies are block, not_suspend and normal. These correspond to the portal's block, continue-traffic/storage, and allow choices. Other Plesk policies are not silently converted when importing legacy configuration.

CLI workflow

The advanced API command uses the same published capabilities, company confirmation, ETags and intent handling. Authenticate as the internal administrator and explicitly request administration scopes:

binadit login --scope account:read --scope admin:read --scope admin:write
binadit api /admin/hosting/packages --account 123 --output json
binadit api /admin/hosting/packages/7 --account 123 --output json
binadit api /admin/hosting/packages --method POST --from-file package.json \
  --account 123 --dry-run
binadit api /admin/hosting/packages/7 --method PUT --from-file package.json \
  --version CURRENT_ETAG --account 123
binadit api /admin/hosting/packages/7/actions/reconcile --method POST \
  --version CURRENT_ETAG --account 123

Use the meta.etag / HTTP ETag from the current read. A stale or absent human passkey proof requires fresh browser verification; a service identity cannot substitute for it. Package input contains ordinary configuration, never the Plesk password. Do not invent a new intent after an uncertain result: read and reconcile the original change.

An uncertain supplier response

The portal saves a durable attempt marker before sending a plan-creation request. A timeout or malformed response returns requires_reconciliation: true, a safe change_id and the package version. A new package remains unavailable to order; an update retains the last published commercial configuration.

Open the package and choose Read status again only, or call actions/reconcile with its current ETag and a new intent key. This only retrieves the exact previously generated provider reference; it never sends ADD, SET or DEL. If Plesk did accept the original request, verified readback completes the same change. If the plan cannot be proven, keep the existing change for support investigation.

Continue steps that have not been attempted may create a revision on another server which has never received its ADD. It cannot resend an ambiguous attempt. Never create another Product or reset the attempt marker to work around uncertainty. Changed server routing or revoked administration rights stop the workflow and require explicit review. A legitimate password rotation preserves the server/plan identity; current credentials must still authenticate and return the exact approved plan contract. Credential rotation while a package change is pending is blocked by server administration.

No live Plesk delivery is implied by the contract or local automated checks. Actual publishing requires configured, reachable provider servers; there is no mock-success fallback.

Provider reference

The implementation follows Plesk's service-plan ADD, GET, and limit structure. Plesk documents propagation of SET to existing unlocked subscriptions in configuring service-plan settings.