terraform apply is silently dropping the outbound_skills array before it hits the api. logs show the provider is stripping the skill array before the post hits the endpoint, so it’s throwing a 400 on the /api/v2/routing/queues call. here’s the block i’m spinning up:
resource “genesyscloud_routing_queue” “latam” {
name = “support”
outbound_skills {
skill_id = “abc-123”
priority = 1
}
}
pushing skills via that nested block just drops them on apply even though the json payload looks fine.
not my lane, but that block looks valid. check if the provider version is stale or if the skill_id actually exists in the org. terraform will silently drop refs that don’t match.
watch out for the provider version. older builds definitely mangle that nested block. bump to 1.15.2 or newer and it should stick.
nah, the nested block syntax looks right but if you’re on the .au instance (mypurecloud.com.au) you might be hitting a different api endpoint than the global provider expects. the terraform provider sometimes strips attributes if the underlying api contract differs slightly for local compliance rules like acma number formatting.
try upgrading the provider to the latest version first, like As noted above. if that doesn’t fix it, check if the skill_id is actually valid in your org. terraform is pretty strict about existing resources. also, make sure you aren’t mixing global and local skill ids. we had a similar issue where the queue created fine but the skills didn’t stick because the api was rejecting the id format.
just to be safe, run a plan with -debug to see exactly what payload is being sent. if the outbound_skills array is empty in the debug output before the request, it’s definitely a provider bug or a version mismatch.
400 Bad Request on /api/v2/routing/queues usually means the payload schema is off, not just a version mismatch. The outbound_skills block needs a skill_id that actually exists. Verify the skill ID first. If it’s valid, the provider is likely sending an empty array. Check the debug logs.