Provider guides
Convoy: configuration and operations
An experimental connection and product-schema adapter for Convoy.
On this page
Provider workflow
An experimental connection and product-schema adapter for Convoy. It belongs to the Provisioning module but is not available for production service delivery. Its product draft contains template_id, region, plan. 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 Convoy 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 draft requires organization_id alongside the connection token. Product fields are template_id, region and plan. Convoy’s official Application API guide documents bearer authentication, but this adapter still inherits generic health and server paths. Use documentation for Convoy Panel, not the unrelated freight marketplace with the same name.
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 |
organization_id |
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.