I’m trying to export all our Architect flows for a backup using the CX as Code CLI. The docs say I should be able to run the export command and get a nice JSON file, but I’m just getting an empty array back.
Here’s the command I’m running:
gc cxascode export --output-dir ./backup --include flows
The auth is fine. I can list users and skills without any issues. The gc auth login worked, and I confirmed the token is valid by hitting the /api/v2/users/me endpoint directly.
The output file flows.json looks like this:
[]
I’ve tried adding --recursive and also specifying a specific flow ID, but it still comes back empty. I checked the environment variables and the GENESYS_CLOUD_ORGANIZATION_ID is set correctly.
Is there a specific permission or scope I’m missing for the OAuth token? The user I’m logging in with is an Administrator.
Also, I noticed in the debug logs it’s hitting /api/v2/architect/flows but the response body is just empty.
Anyone else hit this with the latest CLI version?
Cause:
The gc cxascode export command often returns an empty array if the underlying API call lacks the specific scope to read flow definitions or if the organization has a very large number of flows that exceed the default pagination buffer without a filter. It’s also common for the CLI to hang or return nothing if the OAuth token used for login doesn’t include flow:read.
Solution:
Try using the API directly with the Python SDK to verify if the data is actually accessible. This bypasses the CLI abstraction and gives you clearer error messages.
from genesyscloud import platform_client
# Initialize the client
client = platform_client.create()
# Get the Flow API instance
flow_api = client.flow_api
try:
# Fetch flows with a reasonable page size
response = flow_api.get_flows(page_size=25, expand=['skills', 'settings'])
if response is not None and response.entities:
print(f"Found {len(response.entities)} flows.")
# Save to JSON manually
import json
with open('flows_backup.json', 'w') as f:
json.dump(response.entities, f, indent=2, default=str)
else:
print("No flows returned. Check scopes.")
except Exception as e:
print(f"Error: {e}")
If the SDK returns flows but the CLI doesn’t, it’s likely a CLI bug with the --include flag parsing. Also check your token scopes. You need flow:read. If you generated the token via the CLI login, ensure you didn’t select a restricted client.
3 Likes
The suggestion about the flow:read scope is spot on. I’ve run into this exact issue when setting up our DevOps pipelines. The CLI relies heavily on the scopes attached to the OAuth token used during gc auth login. If you used the default web login flow, it might not have grabbed all the necessary permissions for Architect resources.
You can verify the active scopes by checking the token details in the CLI output or by hitting the /api/v2/oauth2/introspect endpoint. If flow:read is missing, you’ll need to re-authenticate using a client credentials flow with a service account that has the Architect Admin role, or ensure your user file has the correct permissions.
Here is a quick way to test the API directly with curl to confirm the token works:
curl -X GET "https://api.mypurecloud.com/api/v2/architect/flows" \
-H "Authorization: Bearer YOUR_TOKEN_HERE" \
-H "Content-Type: application/json"
If this returns an empty array, double-check the org settings. Sometimes flows are archived and won’t show up in the default export. Also, make sure you aren’t filtering out disabled flows accidentally.
Cause:
From a migration planning perspective, an empty JSON array typically indicates either an OAuth scope gap or a pagination threshold being triggered when your environment is carrying a high volume of Architect flows. During hybrid PureConnect transitions, we frequently encounter read access restrictions for standard service accounts unless flow:read and flow:export are explicitly whitelisted in the IAM configuration. The CLI defaults to a conservative buffer, and if your registry contains nested sub-flows or archived versions, it will silently truncate the payload to prevent timeout errors. This is a common risk during the discovery phase, particularly when legacy IVR structures and skill mapping dependencies haven’t been fully decoupled.
Solution:
To protect your migration timeline and mitigate cutover risks, I recommend forcing the CLI to traverse the complete flow tree by appending the --recursive flag and validating your token scopes prior to execution. You can verify the current permissions with:
gc auth token-info | grep scope
If flow:read isn’t present, re-authenticate using the custom scopes parameter to align with your migration runbook. For the export itself, override the default pagination limits by adjusting the buffer size:
gc cxascode export --output-dir ./backup --include flows --recursive --max-items 500
Silent backup failures can quickly derail a cutover window, so locking down service account permissions ahead of the migration phase is critical. I always advise running a dry run in a sandbox org first to confirm the JSON structure aligns with your target IVR hierarchy and skill routing logic. Also, audit your archived flow count beforehand, as legacy versions will inflate the payload and impact export duration. Schedule the full extraction during off-peak hours to prevent Architect API throttling.
Could you share which IAM role is currently assigned to the service account running this export? Additionally, are you planning to purge archived flows before the cutover, or will you be carrying them over for compliance and audit purposes? Let me know how your sandbox validation is tracking, and I can help map out a risk register for the flow migration phase.