Provider guides
DirectAdmin: configuration and operations
An experimental connection and product-schema adapter for DirectAdmin.
On this page
Provider workflow
An experimental connection and product-schema adapter for DirectAdmin. It belongs to the Provisioning module but is not available for production service delivery. Its product draft contains domain, package, username. This catalogue entry documents the source boundary, not a working automated hosting offer.
Requirements
Agovena Core ^0.0.1. Enable Provisioning before this extension.
This extension is not marked production-ready. Validate its supported workflow in your own test environment before accepting customer orders.
Set up the package
Keep the extension disabled for customer-facing products. In an isolated development installation, enable Provisioning first and review the declared DirectAdmin connection fields. Store credentials only in the protected server settings and leave verify_tls enabled. The connection timeout defaults to 20 seconds. Do not send real customer orders to this adapter.
Provider-specific boundaries
The schema requires api_username, but the current HTTP class inherits bearer-token headers and the generic /api/v1/servers path. Official DirectAdmin documentation describes Basic authentication and login keys. This difference must be resolved in the adapter; entering a login key in a field does not change its authentication protocol.
The following configuration contract is useful for developers planning the integration, not as a production setup recipe. Required fields describe the draft connection form; the product fields above do not have required validation in their definitions. The shared client calls /api/health for its connection test. A green response there does not exercise account creation, ownership checks, cancellation or resource accounting.
Before offering this provider to customers, a provider-specific implementation must replace the unsupported lifecycle and demonstrate the intended vendor requests, response validation, resource ownership and recovery behavior. Keep a manual fulfillment process or choose a separately validated adapter meanwhile. Do not bypass the unsupported guard, disable TLS checks or point the API URL at a different service merely to satisfy the health probe. 2
Configuration contract
| Field | Type | Required | Secret | Default |
|---|---|---|---|---|
api_url |
string |
Yes | No | Empty |
api_token |
string |
Yes | Yes | Empty |
api_username |
string |
Yes | No | Empty |
verify_tls |
boolean |
No | No | true |
timeout |
string |
No | No | "20" |
These are the declared manifest fields. A field marked optional may still be required by an API operation, as described above. Store secret values only in protected settings, never in product descriptions, URLs or shared examples. 1
Operation and failure handling
Provisioning, activation, suspension, reactivation, termination, plan changes, status synchronization and panel actions deliberately raise an unsupported-operation validation error through the shared base class. Capacity lookup is also unsupported in the shared HTTP client. A health request can run, but successful connectivity does not unlock these operations or prove vendor API compatibility.