DigitalOcean API v2 and HTTP client retry: how to avoid duplicate droplet creation

Goal

Design a retry strategy for POST /v2/droplets that guarantees at most one droplet is created, even when the client automatically resends a failed request.

Constraints

• DigitalOcean’s v2 REST API does not expose idempotency headers for droplet creation.
• Rate‑limit responses (429) include a Retry‑After header but do not indicate whether the write has been recorded.
• Duplicate name attempts may return 409 Conflict, but the behavior is not guaranteed for all duplicate scenarios.
• Client‑side deduplication relies on name uniqueness or pre‑checking the droplet list, both of which can fail in race conditions.

Unresolved Decision

Without an API‑level idempotency key, the community must decide how a client can safely retry a droplet creation without causing double charges or orphaned resources.

Specific Questions

1. Does DigitalOcean plan to introduce an idempotency key for POST /v2/droplets, and if so, what header or query parameter would be used?
2. In the absence of API‑level support, what client‑side patterns (e.g., unique name generation, pre‑query checks, or idempotent transaction IDs) are recommended to collapse duplicate creation attempts?
3. How should a client interpret a 409 Conflict response to ensure that a retry does not result in a second droplet, especially when name collisions are possible due to case insensitivity?