Provider guides
Virtualizor: configuration and operations
An experimental connection and product-schema adapter for Virtualizor.
On this page
Provider workflow
An experimental connection and product-schema adapter for Virtualizor. It belongs to the Provisioning module but is not available for production service delivery. Its product draft contains plan_id, location. 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 Virtualizor 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 connection draft requires both api_token and secret api_secret. Its HTTP class sends bearer authentication plus X-API-Secret and uses /api/v1/servers. Official Virtualizor Admin API documentation describes an Admin API Key and API Password. The adapter must explicitly map that vendor protocol; do not assume the current header shape is a verified implementation.
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_secret |
string |
Yes | Yes | 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.