POST /api/v2/interactions/scripts returns HTTP 403 Forbidden with error code “InvalidCredentials” or “AccessDenied”. The response body indicates that the application lacks the necessary permission to execute this action, despite the OAuth scope including script:write.
We are developing a premium AppFoundry application designed to standardize agent scripts across multiple Genesys Cloud partner organizations. The architecture utilizes a central management plane that authenticates via multi-org OAuth2 flows. While basic CRUD operations for creating and retrieving scripts work seamlessly across all target orgs, attempting to update existing script versions or publish changes triggers the 403 error consistently. This behavior is isolated to the script publishing endpoint and does not affect other WFM or Architect resources.
The environment details are as follows: we are using the Genesys Cloud REST API v2 endpoints directly via HTTP clients, not the SDK, to minimize latency. The OAuth token is generated using the client credentials flow with the script:write and script:read scopes explicitly granted. The application has been deployed to the AppFoundry marketplace and installed in three distinct customer orgs. Two orgs function correctly, but one specific org, which operates on a BYOC edge deployment in the US-East region, consistently rejects the update requests.
We have verified that the service account associated with the application has the Administrator role and full access to the Scripting resource. Additionally, the script IDs are valid and correspond to active scripts within that org. No custom permissions or role restrictions appear to be blocking the action based on our initial audit. Given the intermittent nature across different orgs, we suspect a potential issue with how the multi-org token propagation handles specific edge configurations or a caching issue on the script service layer.
Has anyone encountered similar permission discrepancies when updating scripts via API in a multi-tenant partner setup? We are looking for insights into potential edge-specific restrictions or token scope limitations that might not be documented in the standard API reference.