Can anyone clarify the current state of WebRTC softphone configuration management via the Genesys Cloud Terraform provider? Attempting to deploy genesyscloud_webrtc_settings results in a consistent 400 Bad Request during terraform apply. The error payload indicates a validation failure on the webrtc_enabled field, despite the value being set to true as a boolean in HCL.
Using provider version 1.15.6. The environment is a standard Genesys Cloud org with WebRTC enabled at the org level. Manual configuration via the Admin portal works without issue. The API documentation suggests the resource should be manageable via REST, but the Terraform resource seems to expect a different schema or is hitting a deprecated endpoint.
HCL snippet:
resource "genesyscloud_webrtc_settings" "main" {
webrtc_enabled = true
stun_servers = ["stun.l.google.com:19302"]
turn_servers = []
}
Error output:
Error: Error creating WebRTC settings: 400 Bad Request
Response body: {"errors":[{"message":"Invalid value for webrtc_enabled. Expected string, got boolean."}]}
The OpenAPI spec for /api/v2/organizations/webRTC lists webrtc_enabled as a boolean. However, the error message implies the API expects a string representation (“true”/“false”). This discrepancy causes the Terraform provider to fail validation before sending the request, or the provider is serializing the boolean incorrectly for the specific API version in use.
Has the provider been updated to handle this string conversion, or is there a workaround to force the string type in HCL? Using "true" instead of true results in a type mismatch error from Terraform itself, as the schema defines the attribute as Type: schema.TypeBool.
This blocks our automated infrastructure promotion pipeline. The issue persists across multiple environments (Dev, Stage). Manual API calls using curl with a JSON body containing "webrtc_enabled": true succeed, confirming the API accepts the boolean. The issue appears isolated to the Terraform provider’s serialization logic or schema definition.
Running on macOS Sonoma, Terraform 1.6.4. Any insights on whether this is a known bug or a documentation gap?