Need some help troubleshooting division scoping logic in our k6 load tests. We are hitting 403 FORBIDDEN when the service account tries to fetch users outside the default division. The client is configured with division_id but the API ignores it during token issuance.
Here is the current client registration payload. We expect the resulting access token to be restricted to div_bpo_alpha, but it returns a global scope.
{
"name": "bpo-test-client",
"division_id": "div_bpo_alpha",
"grant_types": ["client_credentials"]
}
Is there a specific API call or attribute I need to set on the client to enforce division-level isolation? The standard documentation only mentions global clients. I need this for accurate multi-tenant simulation.
It depends, but generally… 403 Forbidden indicates the token is valid but lacks permissions. The division_id in the client config does not restrict token scope automatically. You must explicitly request the division:read scope during the client_credentials grant.
curl -X POST https://api.mypurecloud.com/oauth/token \
-H "Authorization: Basic <encoded_client_id_secret>" \
-d "grant_type=client_credentials&scope=division:read"
Verify the returned JWT. If the division_id claim is missing, the API server ignores your intended restriction. Ensure the service account is actually added to div_bpo_alpha in the admin console.
Check your token introspection response. The suggestion above correctly identifies the missing scope, but the execution often fails due to how the Basic Auth header is constructed in automated tests.
Cause:
The division_id is a filter for resource retrieval, not a token claim. Without division:read, the platform ignores the division context entirely, resulting in a global token that still lacks explicit division permissions for sensitive resources like user data.
Solution:
Ensure your curl or SDK client includes the specific scope and validates the division_id in the response payload.
curl -X POST https://api.mypurecloud.com/oauth/token \
-H "Authorization: Basic ${BASE64_CLIENT_ID_SECRET}" \
-d "grant_type=client_credentials&scope=division:read routing:user:read"
For distributed tracing, inject the resulting token into your OpenTelemetry span attributes. This ensures that if a 403 occurs, you can correlate the exact scope set against the failed API call in Jaeger. Verify the division_id is present in the decoded JWT claims to confirm multi-tenant isolation is active.
It depends, but generally… you are misinterpreting the token scope. The division_id in the client config is metadata, not a permission boundary. The 403 persists because the token lacks explicit division permissions. Use this payload to enforce the constraint during issuance:
{
"grant_type": "client_credentials",
"scope": "division:read",
"division_id": "div_bpo_alpha"
}
The documentation actually says “the division_id parameter in the token request is ignored for client_credentials grants” so your payload is fundamentally flawed. Use the division header on the resource call instead.
curl -H "Authorization: Bearer <token>" \
-H "Division-Id: div_bpo_alpha" \
https://api.mypurecloud.com/api/v2/users