I can’t seem to figure out why the import command fails with a 404 error when I try to bring existing Genesys Cloud users into my Terraform state. I am building a MuleSoft orchestration layer that relies on the Terraform provider to manage user lifecycle events before triggering downstream API calls. The users exist in the platform, and I can fetch their details via the REST API without issue.
I have the user IDs from the platform. I run the following command:
Error: GET https://api.mypurecloud.com/api/v2/users/12345678-1234-1234-1234-123456789012: 404 Not Found
You can import existing resources into your Terraform state by using the terraform import command. This allows you to manage resources that were created outside of Terraform.
I verified the ID format is valid. I also checked that the OAuth token used by the provider has the user:view scope. Since I am dealing with a legacy data sync, I need these resources in state to prevent drift. Is there a specific attribute or endpoint mismatch in the genesyscloud provider that causes this, or am I missing a step in the authentication handshake for the import process?
It varies, but usually the docs state “import requires exact id match” so verify your id format. use terraform import genesyscloud_user.test <id>. if it fails, check permissions. copy-paste this to debug: curl -X GET https://api.mypurecloud.com/api/v2/users/<id>. ensure scope is user:read.
TL;DR: Ensure your Terraform state import command uses the exact UUID format without URL encoding or trailing slashes, and verify the provider configuration matches the specific environment base URL.
Make sure you are passing the raw UUID string directly to the import command. The 404 error often stems from subtle formatting issues in the ID argument rather than actual permission denials. Since you confirmed the REST API call works, the issue is likely in how Terraform serializes the import identifier.
Here is the robust pattern I use in my CI/CD pipelines to validate the ID before attempting the import. This script ensures the UUID is clean and checks for existence via the Python SDK before invoking terraform import.
import subprocess
from platformclientv2 import PlatformClient, UserApi
def safe_import_user(user_id, tf_resource_id):
platform_client = PlatformClient()
user_api = UserApi(platform_client)
# Validate user exists via SDK first
try:
user = user_api.get_user(user_id)
print(f"User {user.name} (ID: {user.id}) found. Proceeding with import.")
# Execute terraform import with exact ID
cmd = f"terraform import {tf_resource_id} {user_id}"
result = subprocess.run(cmd, shell=True, capture_output=True, text=True)
if result.returncode != 0:
raise Exception(f"Terraform import failed: {result.stderr}")
print("Import successful.")
except Exception as e:
print(f"Failed to validate or import user: {str(e)}")
# Usage
safe_import_user("a1b2c3d4-5678-90ab-cdef-1234567890ab", "genesyscloud_user.primary_agent")
The Terraform provider expects the ID to match the internal database key exactly. If you copied the ID from a browser URL, ensure you stripped any query parameters or fragments. Also, verify that your genesyscloud provider block in your .tf file points to the correct base_url (e.g., api.mypurecloud.com vs api.eu.purecloud.com). Mismatched environments cause silent 404s during import because the provider queries the wrong region. Check your terraform plan after import to ensure attributes are correctly mapped.
The easiest fix here is this is to ensure the import ID matches the exact UUID format without URL encoding, as detailed in this guide: https://support.genesys.cloud/articles/terraform-import-uuid-format. Verify the user:read scope is active in your client credentials to avoid silent 404s.
The quickest way to solve this is to verify the OpenAPI spec definition for the User resource, as the Terraform provider often maps the import ID to the internal database key rather than the public UUID. The 404 error suggests the provider is hitting a non-existent endpoint path constructed from a malformed ID. Check the spec for User to see if the id field is derived or stored. If you are using a custom SDK template, ensure the model generation respects the x-terraform-import extension in the spec. Use the following curl to validate the raw ID format against the API directly before passing it to Terraform, ensuring no URL encoding artifacts are present.