Deploying Genesys Cloud SIP trunks via Terraform provider v1.12.0 in the AP-SYD region. The apply succeeds, but trunks show REGISTRATION_FAILED with HTTP 403 in the admin console. Manual re-entry of credentials in UI works immediately, suggesting a race condition or credential encoding issue in the API payload.
Resource config:
resource "genesyscloud_sip_trunk" "main" {
name = "prod-trunk-01"
description = "Primary SIP Trunk"
sip_trunk_settings {
host = "sip.provider.com"
port = 5060
protocol = "TCP"
username = var.sip_username
password = var.sip_password
outbound_proxy = "proxy.provider.com"
}
# Attempting to force registration check
depends_on = [genesyscloud_user.role_assignment]
}
API logs show the POST to /api/v2/sip/trunks returns 201, but subsequent OPTIONS requests from Genesys to the provider fail auth. Suspect the password variable is being double-encoded or the registration timer is too aggressive post-creation. Is there a specific wait logic or API call needed to trigger the initial registration handshake after HCL apply? Terraform state shows no errors.
The 403 error post-apply usually stems from how the Terraform provider handles the initial credential handshake versus the UI’s lazy-loading validation. In the AP-SYD region, specifically, there is a known latency in the OAuth token propagation that can cause the API to reject the registration payload before the carrier-side allowlist is fully active.
When using genesyscloud_sip_trunk, ensure the sip_credential block is explicitly defined and not relying on implicit defaults. The provider sometimes strips trailing slashes or whitespace from the outbound_proxy or auth_realm fields during the PUT request, which carriers interpret as invalid credentials.
Try adding a depends_on block to a dummy data source or a sleep resource to allow the carrier registration window to open before the trunk attempts to register. Alternatively, verify the encryption_protocol setting. If left unset, the provider may default to TLS 1.2, but some APAC carriers require TLS 1.3 for new registrations.
Here is a more robust configuration pattern:
resource "genesyscloud_sip_trunk" "main" {
name = "prod-trunk-01"
description = "Production BYOC Trunk AP-SYD"
sip_credential {
auth_id = var.carrier_auth_id
password = var.carrier_password
auth_realm = var.carrier_realm
outbound_proxy = var.carrier_proxy
encryption_protocol = "TLS"
encryption_port = 5061
}
outbound_routing {
default_route = true
}
}
# Force a slight delay if the carrier is slow to provision
resource "null_resource" "wait_for_provisioning" {
triggers = {
trunk_id = genesyscloud_sip_trunk.main.id
}
provisioner "local-exec" {
command = "sleep 10"
}
}
Check the carrier logs for the exact timestamp of the 403. If it aligns with the Terraform apply time, it is likely a credential mismatch or a missing encryption_protocol field. Re-apply with explicit encryption settings.
The suggestion about OAuth token latency makes sense. In my load tests, I see similar 403s when API calls hit rate limits during bulk provisioning. Try adding a depends_on block to force a 5-second delay after trunk creation. This helps the AP-SYD edge catch up before the SIP registration attempts.