Genesys Cloud CX as Code: Exporting full org config for DR in Kotlin

We’re setting up a disaster recovery pipeline for our Genesys Cloud org. The goal is to export the entire configuration-queues, flows, users, integrations-so we can spin up a mirror instance if needed.

I’m writing a Kotlin script to handle this. I started with the genesyscloud CLI because it seemed like the obvious choice:

genesyscloud cxascode export --config-file=dr-export.yaml --output-dir=./backup

But the CLI hangs on large orgs, and it doesn’t give me much control over error handling or retries. I’d rather do this programmatically in Kotlin so I can log specific failures and retry transient 429s.

I looked at the Terraform provider source code to see how it handles exports. It uses the genesyscloud package under the hood, but I’m not sure if that’s exposed as a stable API for external use.

My current approach is to use the Genesys Cloud Kotlin SDK to fetch resources individually. Here’s a snippet for fetching queues:

val api = GenesysCloudApi.build().apiClient
val queuesApi = QueuesApi(api)
val response = queuesApi.getQueues(pageSize = 100)
if (response.statusCode == 200) {
 response.body?.entities?.forEach { queue ->
 // serialize to JSON
 }
} else {
 logger.error("Failed to fetch queues: ${response.statusCode}")
}

This works for queues, but it’s incredibly slow. I have to paginate through thousands of users, skills, and flow versions. Plus, I’m missing dependencies between resources. For example, a flow might reference a specific queue ID. If I export them separately, how do I ensure the IDs match in the DR environment? Do I need to map UUIDs to something else?

Is there a bulk export API endpoint I’m missing? Something like GET /api/v2/cxascode/export that returns a tarball or JSON structure of the whole org? Or is the CLI the only supported way?

Also, how do I handle secrets? API keys, OAuth client secrets, and third-party integration credentials aren’t included in the resource exports by default. I’d need to export those separately and inject them during the import phase.

Any pointers on the best practice for this? I don’t want to build a fragile script that breaks when Genesys adds a new field to a resource schema.