Looking for advice on a perplexing authentication issue we are encountering within our latest AppFoundry integration deployment. We are developing a premium application that requires deep user context synchronization, and while the multi-org OAuth flow completes successfully, subsequent API calls to retrieve the current user profile are failing. Specifically, we are receiving a 403 Forbidden error when executing GET /api/v2/users/me. The access token is valid, as confirmed by introspection, and the associated service account has been granted the user:read permission at the organization level. However, the error response indicates that the specific user instance lacks the necessary privileges, despite the app having the correct scope. We have verified that the OAuth client credentials are correctly configured in the Genesys Cloud developer portal and that the redirect URIs match our production environment exactly. The issue persists across multiple test organizations, suggesting it is not isolated to a single tenant configuration. We are using the latest version of the Genesys Cloud REST API and have ensured that our HTTP headers include the correct Authorization Bearer token format. Additionally, we have checked the audit logs for any denied permission requests, but they only show the 403 response without further detail on the specific policy violation. Our integration is designed to handle high concurrency, so we are also mindful of potential rate limiting, though the 403 status code points more towards an authorization problem rather than a throttling issue. We have reviewed the AppFoundry documentation regarding user context propagation and confirmed that the app is requesting the necessary scopes during the authorization request. Despite this, the user profile endpoint remains inaccessible. We are currently blocked on progressing to the next phase of development, which relies on fetching user-specific settings and preferences. Any insights into why the user:read scope might not be sufficient or if there are additional hidden permissions required for this endpoint would be greatly appreciated. We are also open to suggestions on alternative endpoints or methods to retrieve the necessary user context without triggering this permission error.