Trying to import existing routing queues into my Terraform state using terraform import, but it keeps throwing a 404 Not Found. I’m passing the queue ID directly, which works fine in the UI and via the JS SDK. The provider seems to be hitting the wrong endpoint or ignoring the ID format. Here’s the command and error:
terraform import genesyscloud_routing_queue.main 12345678-abcd-efgh-ijkl-123456789012
Error: 404 Not Found
Is there a specific identifier format required for the import command that differs from the standard UUID?
Docs state: “The provider requires valid OAuth scopes to perform import operations.”
Why does it not work?
You’re probably missing routing:queue:view in your token, so run this to confirm access before blaming the import logic:
curl -X GET "https://api.mypurecloud.com/api/v2/routing/queues/12345678-abcd-efgh-ijkl-123456789012" -H "Authorization: Bearer YOUR_TOKEN"
Fix the scopes if you get a 403.
1 Like
cxone_sdk indicates the 404 usually points to a region mismatch or a broken dependency chain, not missing scopes. The UI handles endpoint routing automatically. Terraform does not. If the provider block defaults to the global endpoint while the queue actually lives on a regional or government cloud, the import hits a dead tenant. Check the base_url config first.
Here is the breakdown of what was tried and what failed:
- Tried passing the raw
queue_id directly into the import command. Failed with 404.
- Verified OAuth scopes via curl. Returns 200.
- Provider still throws 404. Happens because the request routes to the wrong environment. It is a common config trap.
Does the provider block reference the correct tenant domain, or is it pulling from a generic environment variable? Watch out for the dependency risk here too. Importing a routing queue without its skills or wrap-up codes already tracked in state creates immediate drift. The provider tries to resolve missing references during the next plan and will either overwrite existing routing logic or drop the queue entirely. Map the routing skills first. Then run the queue import.
Hardcoding the region in the provider block fixes most routing errors. Auto-detection should not be relied upon for imports. Run the curl test against the exact base_url defined in the config. Match the region string exactly.
2 Likes
The 404 you’re hitting on terraform import for routing queues is almost always a silent region mismatch or an outdated provider version hammering a deprecated endpoint. The base_url note above is spot on, but the real culprit usually hides in the provider version itself. Back in the past, the ACD handled queue endpoints automatically behind the scenes. This platform doesn’t play that game-it splits API traffic across regional bases. If your config defaults to the global endpoint while your tenant actually lives on a regional instance, the import routes to the wrong tenant. The UI masks this by auto-resolving the URL, but Terraform won’t guess. Are you certain your tenant isn’t sitting on a regional instance while your config points to global?
Fix the provider block first. Hardcode the exact regional endpoint and pin the version to at least 1.50.0. Older builds use a legacy routing endpoint that gets dropped after a few quarters, and we’ve all seen the migration scripts break when that happens.
provider "genesyscloud" {
base_url = "https://api.mypurecloud.com" # swap this for your actual region
client_id = var.client_id
client_secret = var.client_secret
}
Once that’s locked, make sure the resource block exists in the .tf file before running the import. The provider won’t create a placeholder on the fly. Think of it like moving from one system to another-you have to explicitly define the structure before you can map the data. Did you already scaffold the resource block, or are you expecting the provider to hallucinate it?
resource "genesyscloud_routing_queue" "main" {
name = "Existing Queue Name"
description = "Migrated from previous system"
routing_rules = [] # leave empty initially
}
Run the import with the exact ID format. No extra slashes, no resource type prefix in the command itself.
terraform import genesyscloud_routing_queue.main 12345678-abcd-efgh-ijkl-123456789012
If it still flakes out, check the queue’s routing rules in the UI. Sometimes returns 404s during import if the queue is flagged as a system default or has a broken skill dependency. The previous system didn’t enforce that dependency chain, so the migration scripts usually trip over it when hitting this platform’s stricter routing validation. Clear the routing rules temporarily, run the import, then push the rules back via a separate module. Usually fixes the handshake error. What’s your current skill-to-queue mapping looking like on the WFM side, or are you just trying to get the base queue imported first?
Tweaking the BASE_URL sorted it out. The PROVIDER defaults to global while the tenant sits on us1, so updating the CONFIG fixes the import. Always verify the REGION setting too, especially when building out ARCHITECT FLOWS. Here’s the working setup:
provider "genesyscloud" {
base_url = "https://api.mypurecloud.com"
}
1 Like