Looking for some advice on troubleshooting this recurring authentication failure within our multi-tenant Premium App architecture. We are experiencing intermittent 401 Unauthorized errors when attempting to refresh access tokens for secondary organizations using the standard OAuth 2.0 client credentials flow. The initial token acquisition succeeds without issue, but subsequent refresh attempts fail after approximately 15 minutes of inactivity. The error response body indicates that the client_id is valid but lacks the necessary scope to perform the refresh operation, which is confusing because the scope request includes admin:organization:read and admin:user:read. We have verified that the application permissions in the Genesys Cloud admin console are correctly assigned for both the primary and secondary tenant contexts.
Our backend service, hosted on AWS US-West-2, utilizes the Python SDK version 1.28.4 to manage the token lifecycle. The logs show that the request payload matches the specification exactly, including the grant_type set to refresh_token and the correct refresh_token value obtained during the initial handshake. We have ruled out network latency or firewall issues by testing direct connections from our application servers to the Genesys Cloud API endpoints. The problem appears isolated to the token validation logic on the platform side, as the same credentials work perfectly for the primary organization but consistently fail for any newly onboarded secondary tenants within the past 48 hours.
We are currently investigating whether there is a propagation delay for permission updates across the multi-tenant infrastructure or if a specific configuration step is missing during the partner onboarding process. The affected tenants are using the standard US-East region, while our application operates in the Pacific timezone. Any insights into potential scope inheritance issues or known platform-side latency regarding permission replication would be greatly appreciated. We need to ensure our integration remains stable for high-volume API calls without manual intervention to re-authorize the secondary organizations.