Terraform CX as Code: Queue skills block failing with 400 Bad Request

General Discussion
1

Running into a wall trying to define a queue with specific skills in the Genesys Cloud Terraform provider. The genesyscloud_routing_queue resource accepts a skills block, but I keep getting a 400 Bad Request when applying the config. The error message from the provider is generic: “Error creating routing queue: 400 Bad Request”.

Here’s the snippet I’m using:

resource "genesyscloud_routing_queue" "support_queue" {
 name = "Support Team"
 
 skills {
 id = "12345678-1234-1234-1234-123456789012"
 name = "Tier1Support"
 }
}

I’ve verified the skill ID exists in the org via the API. It’s active and assigned to users. I’ve also tried removing the name field inside the skills block, thinking it might be read-only, but that didn’t help. The plan phase looks fine, no errors there. It only fails on apply.

Checked the Terraform logs with TF_LOG=DEBUG. The payload sent to /api/v2/routing/queues looks correct. The skill ID is there. Wondering if the CX as Code provider has a known issue with nested skill assignments or if I’m missing a dependency. Has anyone successfully deployed queues with skills using this provider recently? Need to get this automated before the next release window.

2

The 400 error usually stems from skill IDs being invalid or not matching the expected format in the API payload. The Terraform provider expects the skills block to reference existing skill IDs, not names. If you’re passing names, the API rejects it outright.

Here’s the correct structure using data sources to resolve IDs first:

data "genesyscloud_routing_skill" "support_skill" {
 name = "Support"
}

resource "genesyscloud_routing_queue" "support_queue" {
 name = "Support Queue"
 skills {
 skill_id = data.genesyscloud_routing_skill.support_skill.id
 priority = 1
 }
}

Make sure the skill exists in your org before applying. Also, check the API response body if you can enable debug logging in Terraform (TF_LOG=DEBUG). It often reveals the specific validation failure. We hit this when migrating configs to New Relic dashboards-always verify the ID resolution step first.