Terraform CXone provider state drift when importing org-level settings

We’re trying to lock down our CXone org configuration using the Terraform CXone provider for disaster recovery purposes. The goal is to export the entire org state, make changes in the UI, and then apply those changes back via code to ensure consistency.

I ran terraform import on a few resources, but it’s failing hard on org-wide settings. Specifically, the cxone_org resource doesn’t seem to exist in the provider schema, which makes sense, but I need to capture things like cxone_user_default_settings or global cxone_routing_settings.

Here is the I’m using to try and capture the default user settings:

resource "cxone_user_default_settings" "main" {
 default_queue_id = "abc-123"
 # other defaults
}

When I run terraform plan, it wants to destroy the existing settings and recreate them because the IDs don’t match. I tried using terraform import cxone_user_default_settings.main <some-id> but I can’t find the correct ID format for these global resources. The API docs for /api/v2/users/default-settings don’t return an ID in the response body, just the settings object.

Is there a way to force the state to match the existing remote state without destroying it? Or is the provider just not capable of managing these specific resources yet? I’ve checked the provider issues on GitHub and saw some open tickets about missing resources, but nothing specific to this.

Also, the cxone_integration resource is throwing a 400 error when I try to import an existing webhook integration. The error says “Invalid integration type” even though I copied the type string directly from the API response.

{
 "error": "Invalid integration type",
 "status": 400
}

I’m stuck. If the provider can’t handle the full export, we might have to write a custom script to pull everything via the REST API and store it in S3. But I’d rather use Terraform if it’s possible. Any ideas on how to bypass this import issue?