Quick question, has anyone seen this weird error? with SIP trunk registration failing across tenant boundaries.
Background
Deploying a Premium App via AppFoundry handling multi-org OAuth for SIP trunk provisioning.
Issue
Post to /api/v2/telephony/providers/edges/siptrunks returns 403 Forbidden. Credentials are valid in the primary org but fail in secondary tenants.
Troubleshooting
Verified OAuth scopes include telephony:provider:write. SDK v5.2.0. Any known restrictions on cross-org SIP provisioning?
Have you tried isolating the OAuth token scope from the SIP trunk provisioning payload? It seems like the 403 might be masking a deeper issue with token validation across tenant boundaries. In our load tests, we often see auth failures when the token isn’t explicitly scoped for the target org’s telephony resources.
POST /api/v2/telephony/providers/edges/siptrunks
HTTP/1.1 403 Forbidden
{“message”:“Forbidden”,“code”:“forbidden”,“status”:“403”}
The issue usually isn’t the SIP trunk config itself, but how the OAuth client is handling the multi-tenant context. If you are using a standard OAuth client, it might not have the necessary permissions to provision resources in a different org, even if the user is authorized.
Try switching to a service account with explicit telephony:provisioning scopes for the target org. Here is a quick JMeter config snippet to verify the token scope before hitting the endpoint:
<HTTPSamplerProxy guiclass="HttpTestSampleGui" testclass="HTTPSamplerProxy" testname="Check Token Scope" enabled="true">
<elementProp name="HTTPsampler.Arguments" elementType="Arguments">
<collectionProp name="Arguments.arguments">
<elementProp name="" elementType="HTTPArgument">
<boolProp name="HTTPArgument.always_encode">false</boolProp>
<stringProp name="Argument.value">${access_token}</stringProp>
<stringProp name="Argument.metadata">=</stringProp>
</elementProp>
</collectionProp>
</elementProp>
<stringProp name="HTTPSampler.path">/api/v2/oauth/tokeninfo</stringProp>
</HTTPSamplerProxy>
If the tokeninfo response doesn’t include the correct org_id or telephony scopes, that is your bottleneck. We saw similar 403s in Singapore when the token was generated for the parent org but the SIP trunk was being created in a child org. Ensure the OAuth flow explicitly requests the target org’s context. Also, check if the app has the required telephony:edges:write permission in the Genesys Cloud admin console. It is easy to miss that checkbox during initial setup.
TL;DR: Check your OAuth scopes.
The telephony:all scope is mandatory for SIP trunk creation, unlike Zendesk where ticket creation was more permissive. Add it and retry.