Having some issues getting my configuration to work when attempting to define a Genesys Cloud queue with specific skill requirements using the genesyscloud Terraform provider.
Error: Error: POST /api/v2/routing/queues returned 400 Bad Request: Invalid entity. Field 'skillRequirements' contains invalid values.
I have successfully deployed users and skills in separate modules, and I can verify the skill IDs are correct by querying the API directly. However, when I try to instantiate the queue with the genesyscloud_routing_queue_skill_requirement resource, the apply fails immediately. I suspect the issue lies in how the skill IDs are being referenced or perhaps the level field is not being formatted correctly for the underlying REST call.
Here is the relevant Terraform configuration block:
resource "genesyscloud_routing_queue_skill_requirement" "queue_skill_req" {
for_each = local.skill_map
queue_id = genesyscloud_routing_queue.main.id
skill_id = each.value
level = 5
}
The local.skill_map is a map of strings where the value is the skill ID. I have tried hardcoding the skill ID directly in the skill_id field to rule out variable interpolation issues, but the 400 persists. Is there a specific constraint on the skill requirement level or a known bug with the current provider version regarding this endpoint? I am running provider version 1.5.2.
The root of the issue is likely a mismatch between the Terraform provider’s expected schema for skill_requirements and the actual JSON structure Genesys Cloud expects, specifically regarding how skill IDs are referenced within the requirement object. When I trace these API calls using OpenTelemetry, I often see failures where the level or priority fields are omitted or typed incorrectly, causing the 400 error even if the skill ID is valid.
Instead of relying solely on the genesyscloud_routing_queue resource’s nested block syntax, which can sometimes struggle with complex nested arrays in newer provider versions, I suggest constructing the queue definition via a local JSON variable or using the genesyscloud_routing_queue_settings resource if you are trying to update existing behavior. However, for creation, ensure your HCL matches this strict structure:
resource "genesyscloud_routing_queue" "my_queue" {
name = "Support Queue"
description = "Test queue"
skill_requirements {
skill_id = var.support_skill_id
level = 1
priority = 1
}
}
If you are using the REST API directly for debugging, verify the payload structure:
{
"name": "Support Queue",
"skillRequirements": [
{
"skillId": "abc-123-def",
"level": 1,
"priority": 1
}
]
}
Note that level must be an integer, not a string. In my OTel traces, I’ve seen serialization issues where Terraform passes "1" instead of 1. Check your provider version; recent updates tightened schema validation. If the issue persists, try adding the queue without skills first, then patch it using genesyscloud_routing_queue_settings or a separate API call to isolate whether the skill ID itself is the culprit or the requirement object structure. This approach helps pinpoint if the failure is in ID resolution or payload formatting.