Need some help troubleshooting why my terraform import command keeps bombing out on existing routing queues.

i’ve got a self-hosted n8n pipeline that provisions most of our GC org, but we’ve got legacy queues that predate the IaC rollout. trying to pull them into state so i can manage everything in one repo. ran terraform import genesyscloud_routing_queue.support_queue a1b2c3d4-e5f6-7890-abcd-ef1234567890 and it immediately throws a 404 Not Found. weird thing is, the UUID is straight from the /api/v2/routing/queues endpoint. i even double-checked the auth token in the n8n http node and it hits fine. maybe the import ID needs the full path instead of just the uuid? tried terraform import genesyscloud_routing_queue.support_queue /api/v2/routing/queues/a1b2c3d4… and same error. here’s the resource block i’m using: resource “genesyscloud_routing_queue” “support_queue” { name = “Support-ES” description = “legacy queue” enable_email = false } logs just say Error importing existing resource… 404 Not Found. does the provider expect a different identifier format. checking the provider docs now but the examples are all blank anyway.

resource “genesyscloud_routing_queue” “support_queue” {
name = “Support”

… other config

}

Run import with the ID only, no resource address prefix

terraform import genesyscloud_routing_queue.support_queue a1b2c3d4-e5f6-7890-abcd-ef1234567890

check your syntax. the error usually isn't a 404 from Genesys Cloud, it's Terraform choking on the resource address format. make sure you're not including `genesyscloud_routing_queue.` in the ID argument itself. the command expects `terraform import <resource_address> <id>`.

also verify the provider version. older versions had bugs with queue imports if the `wrap_up_policy` wasn't explicitly set in the config before import. i hit this last week while syncing event webhooks. if it still 404s, try fetching the queue via `GET /api/v2/routing/queues/{id}` directly to confirm the UUID is valid and not deleted. sometimes the UI shows cached data.

This has the hallmarks of a classic case of the provider hitting a scope wall. the terraform plugin for genesys cloud doesn’t always inherit the same oauth scopes as your manual api calls. if you’re using a service account for the tf provider, check that it has routing:queue:read and routing:queue:write. a 404 often means “access denied” in this context, not “doesn’t exist”.

run this quick check to verify the token has the right juice:

curl -X GET "https://api.mypurecloud.com/api/v2/routing/queues/a1b2c3d4-e5f6-7890-abcd-ef1234567890" \
 -H "Authorization: Bearer <YOUR_TF_TOKEN>"

if that returns 403, your service account is missing the scope. also, double check the org id. sometimes the tf config points to a different env than where the queue lives. i’ve seen this bite me when switching between dev and prod profiles. ensure the genesyscloud provider block has the correct base_url set.

it’s annoying when the error message is so vague. usually, it’s just a scope mismatch.