Terraform data source lookup failing with 404 despite existing resource matching name

Running into a wall with the Genesys Cloud Terraform provider (v1.12.3) when trying to reference existing routing queues by name.

I’ve got a queue called “Support - Tier 2” that definitely exists in the org. I’m trying to get its ID so I can assign users to it in a separate module. Here’s the data source block:

data "genesyscloud_routing_queue" "support_tier2" {
 name = "Support - Tier 2"
}

When I run terraform plan, it blows up:

Error: Error reading routing queue: GET https://api.mypurecloud.com/api/v2/routing/queues: 404 Not Found

I’ve checked the API explorer directly with the same token and the queue is right there. The name matches character for character, including the hyphen and the space. Case sensitivity seems to be handled correctly too.

Tried adding a depends_on block pointing to the module that creates the queue, but that didn’t help since the queue is created in a separate run (state import scenario).

Also tried using the genesyscloud_routing_queue resource with import block, but that requires the ID upfront, which defeats the purpose of looking it up by name dynamically.

Is there a known issue with the data source pagination or filtering logic? The queue is on the second page of results if you list all queues, wondering if the data source only checks the first page.

Here’s the full error log snippet:

╷
│ Error: Error reading routing queue: GET https://api.mypurecloud.com/api/v2/routing/queues: 404 Not Found
│ 
│ with data.genesyscloud_routing_queue.support_tier2,
│ on main.tf line 12, in data "genesyscloud_routing_queue" "support_tier2":
│ 12: data "genesyscloud_routing_queue" "support_tier2" {
│
╵

Any ideas on how to force it to search deeper or if I’m missing a parameter?

data “genesyscloud_routing_queue” “support_tier2” {
name = “Support - Tier 2”

optional: add a filter if multiple queues share the name

filter = {

key = “path”

value = “/api/v2/routing/queues”

}

}

The provider sometimes struggles with names containing spaces or special characters like hyphens when resolving data sources. It’s not always a 404 on the resource itself, but rather the lookup failing to match the internal ID correctly. Try adding the filter block if the simple name lookup keeps failing, though honestly, hardcoding the ID is often safer for critical infrastructure.

If you’re still stuck, check the exact spelling. I’ve seen this happen in our WFM scripts where the queue name has a trailing space. It looks identical in the UI, but the API call fails. You can verify the actual name by hitting this endpoint directly:

curl -X GET \
 'https://api.mypurecloud.com/api/v2/routing/queues?name=Support%20-%20Tier%202' \
 -H 'Authorization: Bearer YOUR_TOKEN' \
 -H 'Content-Type: application/json'

Look at the id field in the response. If it returns empty, the name doesn’t match exactly. If it returns the object, grab that ID and use it directly in your terraform config. It saves the headache of data source resolution errors.

Also, make sure you’re using the same environment. If your terraform state is pointing to production but you’re looking at a sandbox queue, you’ll get a 404. Double check your genesyscloud provider block configuration. It’s an easy mistake to make when switching contexts.