What is the reason the genesyscloud sip-trunk command returns a 409 Conflict when provisioning a new trunk against an existing SIP domain in our staging environment? We are automating infrastructure via Terraform (v1.6) and GC CLI (v2.15.1). The domain exists, but the CLI refuses to attach the new trunk. Error payload indicates duplicate resource ID. Is this a known CLI bug or a limitation of the REST API for bulk trunk creation? Running in ap-southeast-2.
This looks like a resource ID collision rather than a CLI bug. When provisioning trunks via the CLI or Terraform, the platform expects a unique external ID if one is provided. If you reuse an ID from a previous failed attempt or a different environment, the API returns a 409 because that resource identifier is already claimed in the staging tenant.
The fix is usually to regenerate the UUID for the trunk resource in your Terraform state or CLI command. Ensure you are not hardcoding the id field unless absolutely necessary for import scenarios. Instead, let the API generate it or use a dynamic provider function.
resource "genesyscloud_sip_trunk" "new_trunk" {
name = "Staging-Trunk-01"
# Do NOT set 'id' here unless importing
# id = "existing-uuid"
sip_domain_id = var.sip_domain_id
}
Check the staging environment for any orphaned trunk records with the same metadata. Sometimes a soft delete leaves the ID occupied. Purging that record or using a fresh ID resolves the conflict immediately. This happens frequently when automating infrastructure changes across multiple environments without clearing state properly.
{
"headers": {
"Content-Type": "application/json",
"Authorization": "Bearer <GC_ACCESS_TOKEN>",
"X-Genesys-External-Id": "unique_trunk_id_v2"
}
}
The X-Genesys-External-Id header is critical here. While the CLI attempts to manage lifecycle, the underlying REST API treats external IDs as immutable keys for idempotency. If a previous failed run left a soft-deleted resource with that ID, the 409 persists until the TTL expires or the ID changes.
In my ServiceNow webhook integrations, I always generate a fresh UUID for every provisioning attempt to avoid this exact collision. The CLI might be caching the ID from a prior failed state file. Check the Terraform state for any lingering resource references to the old trunk. If the domain is shared across multiple tenants or environments, ensure the SIP Domain ID in the payload matches the exact staging tenant identifier.
Also, verify that the codec preferences in the trunk configuration do not conflict with existing trunks on the same domain. The API sometimes throws a generic 409 when it detects a configuration overlap rather than just an ID collision. Cross-reference the response body for specific errors fields to distinguish between ID clashes and config violations.