Feature Description
Please add documented idempotency support for billable operations, especially:
POST /api/vps/v1/virtual-machines
POST /api/billing/v1/orders
For example, support an Idempotency-Key header and return the original result when the same key is retried.
Problem Statement
Agentic and CI-style workflows commonly run across flaky networks, process restarts, and retry loops. For non-billable operations, retrying is usually safe. For purchase/order endpoints, retrying can accidentally create duplicate billable resources unless the API provides an idempotency contract.
Without documented idempotency, clients have to build weaker workarounds such as:
- searching inventory by hostname after a timeout
- comparing recent orders/subscriptions
- sleeping and polling before retrying
- asking a human to resolve ambiguous purchase state
Those workarounds are fragile and hard to make safe.
Proposed Solution
Document and support a header such as:
Idempotency-Key: 2f2e8f70-46d3-4a4a-a828-example
For a repeated request with the same key and same body, the API should return the original order/virtual-machine response instead of creating a duplicate resource.
For a repeated request with the same key and a different body, the API should return a clear conflict error.
It would also help to document:
- retention window for idempotency keys
- which endpoints support idempotency
- whether idempotency is scoped by API token/account
- response behavior while the original operation is still processing
Use Cases
- Retry safely after client timeouts.
- Resume an interrupted agent run without creating duplicate VPSs.
- Build reliable automation around billable Hostinger resources.
- Avoid manual billing cleanup after ambiguous network failures.
Additional Context
The VPS purchase response already has a useful shape with both order and virtual_machine. Idempotency would make that response safe to recover after transient failures.
Are you willing to contribute?
Feature Description
Please add documented idempotency support for billable operations, especially:
For example, support an
Idempotency-Keyheader and return the original result when the same key is retried.Problem Statement
Agentic and CI-style workflows commonly run across flaky networks, process restarts, and retry loops. For non-billable operations, retrying is usually safe. For purchase/order endpoints, retrying can accidentally create duplicate billable resources unless the API provides an idempotency contract.
Without documented idempotency, clients have to build weaker workarounds such as:
Those workarounds are fragile and hard to make safe.
Proposed Solution
Document and support a header such as:
Idempotency-Key: 2f2e8f70-46d3-4a4a-a828-exampleFor a repeated request with the same key and same body, the API should return the original order/virtual-machine response instead of creating a duplicate resource.
For a repeated request with the same key and a different body, the API should return a clear conflict error.
It would also help to document:
Use Cases
Additional Context
The VPS purchase response already has a useful shape with both
orderandvirtual_machine. Idempotency would make that response safe to recover after transient failures.Are you willing to contribute?