Skip to documentation
Binadit
Open portal

Exchange will be rebuilt separately and is unavailable through the API or CLI. Availability in this release

Workflow guides

Markdown

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 and Exchange server administration

This administration requires a real internal administrator with admin:read/admin:write, recent passkey verification and the separate administration flags. The administration context is an explicitly selected company. Service connections, ordinary owners and resellers cannot configure supplier servers.

binadit admin hosting servers list --account 123 --output json
binadit admin exchange servers get 8 --account 123 --output json
binadit admin exchange servers update 8 --account 123 \
  --version 'ETAG_UIT_GET' --set exchange_version=2019-cu15 --dry-run

API: /api/v1/accounts/{account}/admin/hosting/servers and /admin/exchange/servers support GET/POST on the collection and GET/PATCH/DELETE on /{server}. Collections use limit (maximum 100), cursor and meta.next_cursor. An individual read returns the ETag. Updating, deleting and refreshing metadata require If-Match and an idempotency key. A dry run checks the same version and current administration rights.

Create a connection or replace a key

Create a JSON file with private file permissions, or supply the JSON through a trusted stdin source. Secrets do not belong in --set, shell history or command-line arguments. For example, use binadit admin exchange servers create --account 123 --from-file - and supply the JSON through stdin. OpenAPI describes the complete fields and requirements; the API returns only metadata and has_credentials.

Hosting requires hostname, ipv4, username and password (16 to 4096 characters). ipv6, max_websites and is_default are optional. A bare Hosting hostname uses HTTPS on port 8443; an explicit HTTPS origin can specify a different port. The linked private DNS template contains the normal Hosting records and remains visible in the portal. The selected administration context must have one unique existing customer binding for a new template. Password rotation does not overwrite a manually modified DNS template.

Exchange requires hostname as an HTTPS origin, directory_domain and api_key. Optional fields: exchange_version, webmail_url, owner_account_id and is_default. An owner is an explicit active company with one unique customer binding; null makes an unused server shared. A private server cannot be the shared default. New origins contain no authentication information, path, query or fragment.

Omitted credentials are retained during an update. New keys are stored encrypted and read back immediately after storage to check the round trip. Old unreadable Exchange keys are not decrypted, replaced or repaired without an explicitly supplied new key. Provider passwords and tokens never appear in metadata, operation results or example files in this repository.

Retrieve and select Exchange databases

binadit admin exchange servers refresh-databases 8 --account 123 \
  --version 'ETAG_UIT_GET' --dry-run
binadit admin exchange servers refresh-databases 8 --account 123 \
  --version 'ETAG_UIT_GET'

This uses POST .../exchange/servers/{server}/actions/refresh-databases. A dry run makes no supplier connection. Execution reads at most 200 unique, bounded database identities through the existing Exchange provider connection and stores the inventory. The selected database does not change automatically. After this read, select one exact database identity through PATCH with database, a new ETag and a new explicit mutation intent. Ordinary configuration cannot redirect a server already in use to another database.

An existing unreadable key returns provider_credential_unavailable; enter a new key first. An ambiguous provider result does not automatically repeat the stored operation. Investigate the original operation before creating a new intent.

Deletion and existing services

binadit admin hosting servers delete 8 --account 123 \
  --version 'ETAG_UIT_GET' --confirm-server 8

This deletes only unused portal configuration. It does not delete a supplier, DNS template, mailbox or Hosting subscription. Existing local resource references prevent deletion and changes to routing or company ownership. Pending or unknown supplier tasks prevent key rotation and deletion. First demonstrably complete those tasks or migrate the affected services through a dedicated workflow; do not manually change database references to bypass the block.

The new settings use the same portal models, existing encryption and canonical Exchange key storage. Creating configuration does not independently provision a server, mailbox or paid subscription. Hosting package synchronization, supplier imports and transfers have their own contract and acceptance evidence in the function matrix.

Hosting server administration in the portal

Hosting → Servers uses the same authorization, versions and connection checks as the API for creation, updates and deletion. The form preserves the displayed version and requires recent passkey verification. The list is paginated; updating or deleting linked routing is also blocked in the portal.

The edit form never displays the existing Plesk password, including in a hidden field or HTML attribute. Leave the new password blank to retain the existing encrypted value. This prevents an old unreadable key from being silently replaced by an empty password. A valid, unchanged legacy hostname is displayed as an HTTPS address in the form and is not submitted as a new routing change. Other connections require an explicit change with the current version.

Deletion confirms the exact selected local server ID. It does not delete a Plesk server, Hosting subscription or historical DNS template. Links to subscriptions or immutable package-plan versions block deletion and routing changes; unfinished work blocks credential rotation. A completed plan binding does allow explicit password rotation, preserving exactly the same provider identity and plan readback.

After adding a server, the desired Hosting packages must be explicitly confirmed on that server. Server configuration alone does not publish a Plesk plan.