SIP Trunk Config Drift with Genesys Cloud Provider v1.42.0

Voice & Telephony
1

I’m trying to figure out why the Genesys Cloud Terraform provider is failing to reconcile SIP trunk attributes during automated deployments. The environment is AP Southeast, using GitHub Actions for CI/CD.

The pipeline executes terraform apply successfully for most resources, but the genesyscloud_telephony_providers_edges_sip_trunk resource throws a 400 Bad Request error regarding invalid URI format. The error log indicates a mismatch in the outbound proxy configuration, yet the HCL definition matches the current state in the console exactly.

Provider version: 1.42.0
Terraform: 1.7.4

Here is the payload being sent in the HCL resource block:

resource "genesyscloud_telephony_providers_edges_sip_trunk" "main" {
 name = "Primary-SIP-Trunk"
 description = "Main SIP Trunk"
 
 sip_trunk {
 domain = "example.com"
 username = "trunk_user"
 password = var.sip_password
 
 inbound_proxy = "sip.provider.net"
 outbound_proxy = "outbound.provider.net"
 }
}

The API response cites invalid_uri for the outbound_proxy field. Manual verification in the UI confirms the value is correct. Is this a known issue with the provider’s validation logic for proxy URIs? Or is there a specific format requirement for the URI that the provider is not handling correctly during the patch request?

2

Make sure you validate the outbound proxy URI structure before pushing the Terraform configuration. The Genesys Cloud API is strict about SIP URI formatting, and minor deviations often trigger 400 errors during resource reconciliation. While I primarily work with recording exports and digital channel metadata, the principle of sanitizing input data applies here too. Just as we clean Zendesk payloads to avoid schema breaks, you must ensure the outbound_proxy attribute matches the exact regex expected by the Genesys Telephony API.

The provider v1.42.0 has known issues with parsing complex URI strings if they contain unescaped characters or incorrect scheme definitions. Instead of relying solely on the Terraform provider to handle the formatting, consider pre-validating the URI in your CI/CD pipeline. This adds a layer of safety before the API call is made.

Here is a recommended approach to stabilize your deployment:

  • Pre-validate the URI: Add a validation step in your GitHub Actions workflow using a simple script to check the URI format. Ensure it follows the sip:user@domain:port or sips:user@domain:port structure strictly.
  • Use Variables for Complexity: Move the complex URI string into a Terraform variable. This makes it easier to debug and ensures consistent formatting across different environments (dev, staging, prod).
  • Check for Trailing Characters: Common pitfalls include trailing slashes or invisible whitespace. Trim the variable explicitly before passing it to the genesyscloud_telephony_providers_edges_sip_trunk resource.
  • Review API Documentation: Cross-reference the URI format with the latest Genesys Cloud Telephony API docs. Sometimes, specific regions like AP Southeast have slightly different proxy requirements.

If the issue persists, try exporting the current state of a working trunk using the API and comparing the JSON structure with your Terraform output. This often highlights subtle differences in how the provider serializes the data. Focus on the outbound_proxy and host attributes specifically, as these are the most common sources of drift.

3

This is actually a known issue…

  • Check if the SIP URI format matches the strict Genesys Cloud API requirements, similar to how Zendesk macros required specific syntax.
  • Verify the outbound proxy configuration in the Terraform state file for any hidden characters or formatting errors that might cause the 400 error.