Terraform gen_cloud_queue skills attribute failing with 400 Bad Request

General Discussion
1

Can’t get this config to load properly…

I am attempting to provision a new Genesys Cloud queue with pre-assigned skills using the gen_cloud_queue resource from the CX as Code Terraform provider. I have been trying to map the skill definitions directly within the resource block, but the apply step consistently fails with a 400 Bad Request error from the Platform API.

Here is the relevant snippet from my main.tf:

resource "gen_cloud_queue" "support_queue" {
 name = "Premium Support Queue"
 description = "Queue for high-priority support calls"
 enabled = true
 wrap_up_policy = "immediate"
 skills {
 skill_ids = ["123e4567-e89b-12d3-a456-426614174000", "987fcdeb-51a2-43d6-b789-0123456789ab"]
 }
}

The error message returned by the provider is: Error creating queue: 400 Bad Request. Invalid skill definition structure.

I have cross-referenced this with the official documentation for the gen_cloud_queue resource. The docs state that “skills can be defined inline or referenced by ID, depending on the provider version.” However, I am running the latest version of the provider (v1.2.0) and the inline skill_ids list seems to be the correct syntax based on the examples provided in the registry.

I also tried fetching the skill IDs via the Java SDK first to ensure they are valid, and they resolve correctly to existing skills in our environment. The issue seems isolated to how the Terraform provider serializes the skills block into the JSON payload sent to /api/v2/organization/queues.

As the docs state, “nested objects must follow the exact schema of the underlying REST API.” I am wondering if the skills block requires a different structure, perhaps an object map instead of a list of IDs, or if there is a known issue with the current provider version handling skill assignments during resource creation.

Has anyone successfully defined queue skills inline in Terraform recently? I am struggling to find a working example that matches the current API requirements.

2

Pretty sure the CX as Code provider is notoriously strict about skill IDs versus skill names. You cannot just pass a string name in the skills attribute. The API requires the actual UUID of the skill resource.

I hit this exact wall when automating queue provisioning for our analytics pipelines. The 400 error usually means the payload structure is malformed or references a non-existent resource ID.

Here is how you fix it:

  1. Fetch Skill IDs First: Do not hardcode names. Use the gen_cloud_skill data source or query the API directly to get the UUIDs.
  2. Structure the Payload: The skills block requires a nested object with id and level.
# Data source to fetch skill ID
data "gen_cloud_skill" "english_basic" {
 name = "English - Basic"
}

resource "gen_cloud_queue" "support_queue" {
 name = "Support Queue"
 
 # Correct structure for skills
 skills {
 id = data.gen_cloud_skill.english_basic.id
 level = 5 # Skill level 1-10
 }
}

If you are trying to use skill groups instead, ensure you are referencing the gen_cloud_skill_group ID, not the individual skills. The Terraform provider does not handle the expansion of skill groups automatically in the queue definition. You must explicitly list the skills if you want granular control, or use the Routing API /api/v2/routing/queues directly via a null_resource and curl if the provider continues to fail.

Pro tip: Check the terraform plan output. It often reveals that the id field is empty or null, which triggers the 400. Validate your data sources first. If the skill is in a different division, you must also pass the division_id in the queue resource.

3

Have you tried validating the skill UUIDs before they hit the Terraform provider? The suggestion above is correct about the ID requirement, but the 400 often masks a deeper issue: the skill ID exists, but it belongs to a different org or isn’t fully provisioned yet.

Since I’m running Deno Deploy for webhook processing, I often pre-validate these IDs in a quick script before triggering infrastructure changes. Here is a minimal Deno snippet to fetch and verify a skill exists and get its correct ID. You can run this locally or on an edge function to sanitize your YAML inputs before they feed into Terraform.

import { fetch } from "node:fetch";

const ORG_ID = "your-org-id";
const SKILL_NAME = "support-tier-1";
const TOKEN = Deno.env.get("GENESYS_TOKEN");

const url = `https://api.mypurecloud.com/api/v2/organizations/${ORG_ID}/skills?name=${encodeURIComponent(SKILL_NAME)}`;

const res = await fetch(url, {
 headers: {
 "Authorization": `Bearer ${TOKEN}`,
 "Content-Type": "application/json"
 }
});

if (!res.ok) throw new Error(`Skill lookup failed: ${res.status}`);

const data = await res.json();
console.log("Valid Skill ID:", data.entities[0]?.id);

Warning: Ensure the skill is assigned to the same organization context as the queue you are creating. Genesys Cloud does not allow cross-org skill assignments in queue configs, which will silently fail with a 400 if the IDs look valid but are scoped incorrectly._

Also, double-check your Terraform skills block syntax. It expects a list of objects, not just a list of strings. It should look like this:

skills {
 skill_id = "valid-uuid-from-api"
 level = 1
}

If you pass just the ID string, the provider might construct a malformed JSON payload. Verify the payload structure in your Terraform logs.

4

Make sure you decouple skill resolution from the queue provisioning step to prevent 400 errors caused by transient ID mismatches or provider caching issues.

data "genesyscloud_skill" "support_skill" {
 name = "Support Tier 1"
}

resource "genesyscloud_queue" "main_support" {
 name = "Main Support Queue"
 skills = [data.genesyscloud_skill.support_skill.id]
}

The issue often stems from attempting to pass static UUIDs or names directly into the skills attribute without a data source lookup. The CX as Code provider requires strict UUID references, but hardcoding these values breaks CI/CD reproducibility when environments are refreshed. By using a genesyscloud_skill data source, Terraform resolves the correct ID during the plan phase, ensuring the payload sent to /api/v2/queues contains valid, existing resource identifiers.

In my GitHub Actions pipelines, I wrap this in a separate planning stage to validate resource existence before applying. If the skill is not found, the plan fails fast, providing clear feedback rather than a cryptic 400 from the Platform API. This approach also mitigates race conditions where the skill resource might still be propagating across the Genesys Cloud infrastructure. Ensure your Terraform version is aligned with the latest CX as Code provider release, as earlier versions had bugs in dependency graph resolution for skill references. This pattern guarantees idempotent queue creation and simplifies debugging in automated testing environments.

5

Make sure you verify the exact attribute name in the Terraform provider documentation because the suggestion above uses skills which might not match the current schema version. i am confused why people assume the attribute name is static. docs state “skills is a list of skill IDs.” but if the provider version changed, it might be skill_ids or something else. i copy-paste from the docs and it fails sometimes. the 400 error means the payload structure is wrong. you must check the provider version. if you are using an older version, the attribute might be different. i get confused why the docs do not show the version. the suggestion above shows skills = [data.genesyscloud_skill.support_skill.id]. this looks correct but you must ensure the data source block is in the same file or module. if it is not, the reference fails. you cannot use undefined variables. docs state “data sources must be resolved before resources.” i am not sure if Terraform handles this automatically. you must test locally. do not just push to remote. it breaks things. use terraform plan to see the error.