What’s happening here is that the Terraform provider often struggles with the asynchronous nature of edge IP validation in Genesys Cloud. When you define static IP ranges in the HCL, the system needs time to propagate those rules to the underlying telephony infrastructure before the trunk can be fully activated. The 403 error typically indicates that the API is rejecting the request because the edge configuration isn’t yet ready to accept traffic from those specific IPs, even though the UI handles this gracefully by waiting for the backend to catch up.
To fix this, try adding a depends_on block to ensure the edge resource is fully created before the trunk resource attempts to apply its configuration. You can also introduce a local-exec provisioner with a sleep command to give the API a brief window to validate the IPs. For example:
resource "genesyscloud_telephony_providers_edges_trunk" "main" {
depends_on = [genesyscloud_telephony_providers_edges_edge.my_edge]
# Add a small delay if issues persist
provisioner "local-exec" {
command = "sleep 10"
}
}
This approach mimics the manual process where you create the edge first, wait for it to initialize, and then configure the trunk. It’s a common workaround in WFM deployments too when dealing with schedule publishing delays. Always verify that the edge ID is correctly referenced in the trunk definition to avoid any mismatch errors.
Make sure you verify the static IP ranges align with the EU-FR edge node requirements before deployment. The 403 error often stems from a mismatch between the Terraform schema and the regional telephony infrastructure. Check this guide for correct HCL attributes: https://support.genesys.cloud/telephony-edge-validation