CX as Code export hangs on 409 Conflict during bulk org config pull

Trying to script a full org config export for DR purposes using the CX as Code CLI, but it’s failing hard on resource dependencies. I’m running genesys-cloud export --resources all --output ./backup from my local machine, targeting our prod tenant. The process gets about 30% through, dumping a bunch of routing queues and user groups, then it hits a wall.

The error log shows a 409 Conflict when trying to export integrations:api:integration resources. Specifically, it seems to be choking on the OAuth client configurations linked to our custom web app. The CLI output says:

Error exporting resource integrations:api:integration:12345
Conflict: Resource is locked by another process or dependency not met.

I’ve checked the UI, and no one is editing those integrations. I even tried running this during our maintenance window at 2 AM CST to avoid any human interference. The issue persists.

Looking at the raw JSON payload the CLI is sending to the /api/v2/integrations/api/integrations endpoint, it seems like it’s trying to resolve a circular dependency between the integration and the associated oauth:client resource. The export order in the CLI doesn’t seem to account for this. I tried manually exporting the OAuth clients first using --resources oauth:client, but when I run the full export again, it still fails on the integrations.

Is there a way to force the export order or ignore specific locked resources? I don’t want to skip them entirely because I need the full config for DR. I’ve read the docs on genesys-cloud export, but there’s no flag for dependency resolution.

Also, I noticed the CLI doesn’t provide a retry mechanism for 409s. It just crashes. I’ve been manually deleting and recreating the export script, which is tedious.

Any ideas on how to bypass this lock? Or is this a known bug in the latest version of the CX as Code tooling?

The 409 isn’t a bug in the CLI. It’s a dependency order issue. When you run --resources all, the exporter tries to grab everything in a semi-random batch. If it hits an integration before the associated webhook or API endpoint config is fully resolved in the export queue, the conflict check fails because the reference is dangling.

You need to force the export order. Don’t use all. Break it down by layer. Start with the data layer, then the config layer, then the routing layer.

Run this sequence instead:

# 1. Core entities first
genesys-cloud export --resources users,groups,skill-sets --output ./backup/core

# 2. Routing and queues
genesys-cloud export --resources routing-queues,routing-languages --output ./backup/routing

# 3. Integrations last (they depend on the above)
genesys-cloud export --resources integrations:api:integration --output ./backup/integrations

If you still get a 409 on the integration export, check the dependsOn field in the generated JSON for that specific integration. Sometimes the CLI misses a soft dependency on a custom object definition.

You can also bypass the CLI’s internal dependency graph by using the --ignore-conflicts flag, but that’s risky for DR. You’ll end up with broken references in your backup files. Better to fix the order.

Another trick: if you’re exporting a huge tenant, split the integrations export by type.

genesys-cloud export --resources integrations:api:integration --filter "type=webhook" --output ./backup/webhooks
genesys-cloud export --resources integrations:api:integration --filter "type=rest" --output ./backup/rest

The conflict usually happens when the CLI tries to export a REST integration that references a custom object schema that hasn’t been exported yet. By separating them, you ensure the schema exists in the backup before the integration tries to point to it.

Check your integration configs for any hardcoded IDs that might not be resolvable during export. If you see a 409, look at the response body. It usually tells you which resource is causing the conflict.

{
 "errorCode": "concurrent_modification",
 "message": "Resource 'integration-123' depends on 'custom-object-456' which is currently being modified or exported."
}

If that’s the case, export the custom object first.

genesys-cloud export --resources custom-objects --output ./backup/custom-objects

Then retry the integration export.

This approach is slower but way more reliable. The CLI’s all flag is convenient but it doesn’t know your specific dependency tree. You do.

genesys-cloud export
–resources routing:queue,user:group
–output ./backup/layer1-core

genesys-cloud export
–resources integrations:api:integration
–output ./backup/layer2-integrations

The suggestion above about dependency order is spot on, but breaking it down manually is painful if you have hundreds of resources. The CLI actually supports a `--dependency-order` flag in the newer versions (check `genesys-cloud export --help`), which tries to resolve the graph automatically. If that’s not available in your version, or it’s still choking, the real issue is usually that the integration definition references a webhook endpoint that hasn’t been exported yet, or vice versa.

For the `integrations:api:integration` specifically, the 409 often happens because the CLI tries to validate the integration’s `endpointId` against the local export state before that endpoint resource is processed. You can bypass this by exporting the `integrations:api:endpoint` resources first.

```bash
# 1. Export endpoints first
genesys-cloud export \
 --resources integrations:api:endpoint \
 --output ./backup/endpoints

# 2. Then export integrations
genesys-cloud export \
 --resources integrations:api:integration \
 --output ./backup/integrations

If you’re still getting 409s after that, check the integrations:api:integration definition for any webhook or oauth settings that point to external URLs. The CLI might be trying to validate reachability during the export phase if the --validate flag is implicitly set or if there’s a custom validator plugin loaded. You can disable validation with --no-validate to force the export to just pull the JSON definitions without hitting the API for status checks.

genesys-cloud export \
 --resources integrations:api:integration \
 --output ./backup/integrations \
 --no-validate

This usually sidesteps the conflict because it skips the dependency resolution check entirely. Just be aware that the resulting Terraform files might have broken references if you don’t export the dependencies in the correct order later. It’s a trade-off between speed and correctness.