running the cx as code cli to hit /api/v2/architect/api/backup for a full org dr dump and it’s throwing a 403 on the routing queues endpoint. scopes don’t seem to match what the backup job expects, so the queue definitions just drop without logging anything useful. already tried bumping the client to routing:queue:read and architect:api:read, still gets cut off at the division level.
{ "error": "access_denied", "message": "insufficient scope for resource type routing:queue" }
the 403 on routing queues usually comes from division scope mismatch, not just the api scope. the backup endpoint tries to pull resources across all divisions by default, but if the client credentials are scoped to a single division or the ‘default’ division, the api blocks the request for resources in other divisions.
in java sdk we handle this by explicitly setting the division id in the request header. the cli might be missing this context. check if your client has division:read scope. without it, the backup job can’t even list the divisions to iterate through.
try adding division:all or specific division ids to the token request. if you are using machine-to-machine auth, make sure the client is assigned to the divisions containing those queues.
here is how we structure the backup request in java to avoid the scope trap:
ArchitectApi architectApi = new ArchitectApi();
architectApi.setAccessToken(accessToken);
// explicitly set division to avoid 403 on cross-division resources
architectApi.setDivisionId("all");
try {
BackupResult backup = architectApi.postArchitectApiBackup();
System.out.println("Backup initiated: " + backup.getId());
} ch (ApiException e) {
// log the specific error code, 403 vs 409
System.err.println("Backup failed: " + e.getMessage());
}
if the cli doesn’t support setting the division header, you might need to break the backup into smaller jobs per division. the full org backup is heavy on the api server and often hits rate limits before it even gets to the queue definitions.
watch out for the api rate limit on the backup endpoint. it’s quite strict. if you get 429 errors, add a delay between the backup request and the status check.
The backup endpoint isn’t just checking scopes. It’s checking division permissions.
If the client credentials are tied to a specific division, the full org backup fails silently on resources outside that scope. The 403 on routing queues is a symptom of that scope boundary.
Here is how to fix it:
null or the default division ID in the Genesys Cloud admin portal.The Resource Center notes this behavior under “Backup and Restore API Limits”. The endpoint requires cross-division read access for a true full org dump.
{
“client_id”: “your_client_id”,
“client_secret”: “your_client_secret”,
“scope”: [
“architect:api:read”,
“routing:queue:read”,
“organization:read”,
“division:read”
]
}
got it working after digging into the scope definitions. the issue wasn't just the missing `division:read` scope, though that was definitely part of the problem. the backup endpoint actually requires broader organization-level read access to traverse division boundaries correctly. adding `organization:read` to the manifest fixed the 403.
here's what changed. the cli was trying to fetch queue data across all divisions, but the token lacked the authority to list divisions first. without `division:read`, the initial discovery step fails silently, which leads to the weird 403 on the queue endpoint itself. it's a chain reaction.
also, make sure you're not using a user token for this. service accounts behave differently with division scoping. if you're using client credentials, ensure the app is assigned to the correct divisions in the admin console. sometimes the api scope is there, but the app isn't actually linked to the division resource.
here's a quick curl to verify the division listing works before running the full backup:
```bash
curl -X GET "https://api.mypurecloud.com/api/v2/organizations/{organizationId}/divisions" \
-H "Authorization: Bearer {access_token}" \
-H "Accept: application/json"
if that returns a 200 with your divisions, the scopes are likely correct. if it 403s, you’re still missing division:read or the app isn’t assigned to the org. the backup tool is pretty strict about this. it won’t give you a partial dump, it just bails. annoying, but expected.
The division scope issue is definitely the primary blocker, but if you are hitting a 403 on routing queues specifically, you likely also need routing:queue:write for the backup endpoint to function correctly in some org configurations. The backup process sometimes tries to write temporary state or validate queue dependencies.
Here is how I handle this in Python using the genesyscloud SDK. You need to ensure your client is initialized with the correct scopes and that you are not restricting the division context prematurely.
from genesyscloud.platform_client_v2 import PlatformClient
# Initialize client
pc = PlatformClient()
pc.login_client_credentials(client_id="your_client_id",
client_secret="your_client_secret",
scopes=["architect:api:read", "routing:queue:read", "routing:queue:write", "organization:read", "division:read"])
# Get the default division ID
division = pc.get_default_division_id()
# Fetch backup configuration to verify scope access
try:
backup = pc.architect_api.get_architect_backup()
print("Backup config retrieved successfully.")
print(backup.to_dict())
except Exception as e:
print(f"Error retrieving backup: {e}")
If the error persists, check if your organization uses custom divisions for routing queues. The backup endpoint might be trying to access queues in divisions where your service account lacks explicit routing:queue:read permissions. You may need to grant the service account routing:queue:read access in each division individually.
Also, ensure that the genesyscloud CLI tool you are using is up to date. Older versions had bugs with division traversal. Running pip install --upgrade genesyscloud might resolve some of these scope resolution issues. If you are still seeing the 403, try creating a new service account with minimal permissions and adding scopes one by one to isolate the issue.