Terraform SIP Trunk Registration Failing 403 After Provider Update

Architect & Flows
1

Terraform provider v3.6 upgraded from v3.4 yesterday. SIP trunk registration status stuck in FAILED state for the last four hours. Environment is US-East-1. Using OAuth scopes genesyscloud:sip_trunk and genesyscloud:api. Provider logs show 403 Forbidden during POST /api/v2/sipTrunks. Configuration file shows valid externalId mapping to AWS Direct Connect. Anyone seen this after the provider update?

resource "genesyscloud_sip_trunk" "main" {
  name        = "AWS-DC-Trunk-01"
  type        = "EXTERNAL"
  registration {
    enabled = true
  }
}

Plan output indicates no changes needed yet state drifts. Need to force refresh without deleting the trunk.

2

Check the service account permissions first. The provider requires admin level scopes for SIP Trunk creation in some regions. We had similar issues with AWS VPC endpoints blocking outbound calls from the GC region during registration.

Verify if the terraform_state_lock is held by another process. Use terraform state rm genesyscloud_sip_trunk.main then import again.

Ensure the OAuth token refresh logic does not expire during the POST request.

3

SIP Trunk configuration often impacts flow routing downstream. Verify if the trunk ID matches the one in your Flow execution settings. The routeToQueue node requires the exact Trunk ID for accurate reporting metrics.

Sometimes the registration failure is a symptom of an upstream signaling issue rather than the provider itself. Check the sipTrunkStatus endpoint via CLI to see real-time state.

2 Likes
4

PureConnect managed SIP trunks differently than this platform. Moving to Genesys Cloud requires validating the trunk type matches the routing profile exactly. A mismatch here caused similar issues during our migration last quarter.

Ensure the sipTrunkType is set correctly for BYOC scenarios. This looks like a permission boundary issue rather than a network problem.

5

not really a sip guy but i see this permission mess a lot when setting up topic detection rules. the 403 is usually not about the network but the oauth scopes being too narrow. the admin ui lets you do everything because it uses a broad session token, but terraform needs explicit api scopes.

try adding telephony:siptrunk:write to your service account. the genesyscloud:sip_trunk scope might only cover reading the status. we had a similar issue where the provider update changed how it checks for write permissions. it’s stricter now.

also check if the external id is actually unique in your org. if there’s a duplicate somewhere, the api throws a 403 instead of a 409 sometimes. weird but true. just a thought since i mostly deal with keyword spotting precision, not trunk routing.

2 Likes