Just noticed that our latest deployment of a premium outbound dialer integration is failing consistently at the SIP transfer stage. This is occurring specifically when the Architect flow attempts to transfer an active conversation to an external SIP URI hosted on our partner’s infrastructure. The issue appears isolated to tenants that have recently migrated to the new multi-tenant OAuth structure, while legacy single-tenant setups remain unaffected.
The specific node involved is a standard “Transfer to SIP URI” block within a complex IVR flow designed for high-volume agentless callbacks. When the flow executes, the Genesys Cloud platform initiates the SIP INVITE but immediately receives a rejection. The error payload is quite specific, indicating a permissions mismatch rather than a network connectivity issue.
{
"code": "forbidden",
"message": "Transfer target URI is not authorized for this tenant context. Ensure the SIP trunk configuration allows outbound calls to this domain.",
"status": 403,
"apiVersion": "v2"
}
We have verified that the SIP trunk configuration in the Genesys Cloud admin console explicitly allows outbound calls to the target domain for all affected tenants. Furthermore, the OAuth tokens used by the AppFoundry application include the telephony:outbound:write and architect:flows:write scopes, which should theoretically permit this action. The initial connection establishment succeeds, and the call is bridged correctly until the transfer node is reached.
Given that our AppFoundry application manages multiple tenant contexts simultaneously, I suspect there might be a scope limitation or a specific API rate-limiting behavior triggered when the platform attempts to validate the SIP URI against the tenant’s security policies in a multi-tenant environment. The error does not occur during the initial call setup, only during the transfer phase.
Has anyone encountered similar permission conflicts when using the transferToSipUri action in a multi-tenant AppFoundry deployment? We are currently running version 2023.11.0 of the Platform API SDK. Any insights into whether this is a known limitation with multi-tenant OAuth scopes or a configuration nuance we are missing would be greatly appreciated.