I’m trying to figure out why the genesyscloud_routing_queue resource fails during apply when including media_settings for WebRTC softphone enablement. The deployment pipeline (GitHub Actions) runs successfully for standard voice queues, but adding the WebRTC specific configuration triggers a validation error from the API.
The Terraform plan shows no issues. The apply step sends a PUT request to /api/v2/routing/queues/{id}. The response is 422 Unprocessable Entity. The error message is generic: Invalid media_settings structure. No specific field is highlighted in the JSON response body, making debugging difficult.
The environment is Genesys Cloud US-East. The provider version is 1.35.0. The tenant has WebRTC softphone feature enabled in the admin console. Manual creation of the queue with the same settings via the UI works without issues. This suggests a schema mismatch or a missing required field in the HCL definition that the provider does not enforce locally.
Here is the relevant configuration block:
resource "genesyscloud_routing_queue" "webrtc_queue" {
name = "WebRTC Support Test"
description = "Testing WebRTC softphone integration via IaC"
enabled = true
media_settings {
media_type = "voice"
// Attempting to enable softphone
softphone_enabled = true
// Standard timeout settings
answer_timeout_ms = 30000
wrap_up_timeout_ms = 60000
// WebRTC specific flags found in API docs
web_rtc_enabled = true
}
member_flow = "default"
external_flow = "default"
}
The softphone_enabled and web_rtc_enabled boolean fields are present in the OpenAPI spec for the MediaSettings object. However, the Terraform provider documentation for genesyscloud_routing_queue does not explicitly list these nested attributes under media_settings. It only mentions media_type and timeouts.
Is this a known limitation of the current provider version? Or is there a different resource block required to handle WebRTC specific queue configurations? The CLI genesyscloud-routing-queue commands also do not seem to expose a flag for web_rtc_enabled.
Looking for workarounds or confirmation if this is a provider bug. The goal is to have the queue fully configured via code, including the softphone toggle, without manual UI intervention.