How exactly do the OAuth scopes map to the routing queue endpoints when you’re pulling a token from a Studio REST Proxy? Step one: the SNIPPET grabs a bearer token using the client credentials flow and stores it in a global variable. Step two: we pass that token into the header for a GET request against /api/v2/routing/queues. The request looks straightforward enough, but the response keeps bouncing back with a 403 Forbidden.
Here is the exact payload we are getting back: {“code”: “forbidden”, “message”: “Missing required scope: routing:queue:view”}. Wait, that message is actually just my local test output, but the live environment throws a generic 403 with no helpful text. We’ve already assigned admin and routing:queue:view to the service account, yet the REST Proxy still denies it. I’ve checked the token payload in jwt.io and the scope claim definitely lists routing:queue:view. Could the Studio REST Proxy be stripping claims during the handoff, or is there a secondary permission layer on the queue object itself? The snippet logic doesn’t handle the retry loop fine, so it’s purely an auth mismatch.
Checking the scope documentation now…