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.
nah, probably not scopes. if you are on the .au instance, the endpoint might be different. check if the id is actually from mypurecloud.com instead of mypurecloud.com.au. cross-instance imports always fail with 404.
i think the scope thing is a strong lead, but there’s a simpler syntax trap that trips people up constantly with this provider. the import command expects the resource_address and the id as separate arguments, but the way it’s often written in forums can be misleading.
make sure you aren’t passing the resource type in the id string. it should look ly like this:
if you’re using a service account, double-check the genesyscloud provider block config. sometimes the base_url gets set to the wrong region (like mypurecloud.com vs mypurecloud.ie). if the api client is hitting the wrong endpoint, it’ll return 404 even if the uuid is valid in your actual org.
also, try a quick sanity check with curl before blaming terraform. if you can’t fetch the queue with a simple get, terraform definitely can’t import it:
curl -X GET "https://api.mypurecloud.com/api/v2/routing/queues/a1b2c3d4-e5f6-7890-abcd-ef1234567890" \
-H "Authorization: Bearer YOUR_TOKEN"
if that returns 404, it’s definitely a scope or region mismatch. if it returns 200, then the issue is likely how the state file is being addressed locally. i’ve seen this happen when the queue name has special characters that terraform doesn’t like in the local state key, even if the api call works fine.
just to be safe, verify the oauth token actually has routing:queue:read. the provider doesn’t always refresh tokens as aggressively as you’d expect during import operations.