Terraform plan fails on PR with 401 Unauthorized in GitHub Actions

General Discussion
1

Trying to set up the configuration for a CI/CD pipeline for Genesys Cloud using the Terraform provider. The terraform plan step fails during the Pull Request check with a 401 error, even though the secrets are set.

│ Error: Requested account not found
│ 
│ with provider["registry.terraform.io/mypurecloud/genesyscloud"],
│ on main.tf line 1, in provider "genesyscloud":
│ 1: provider "genesyscloud" {

I am using the OAuth client credentials flow. How do I scope the permissions correctly for read-only plan operations?

2

TL;DR: Check your environment variable syntax in the GitHub Actions workflow file.

The easiest way to fix this is to ensure the genesyscloud provider block uses the exact variable names genesyscloud_client_id and genesyscloud_client_secret instead of custom aliases, as the Terraform provider does not auto-map generic OAuth secrets. Verify the variables are exported in the env block of the terraform plan step, not just the job level, to avoid scope issues during the execution context.

3

main.tf

terraform {
backend “s3” {
bucket = “gc-tf-state-prod”
key = “env/${var.environment}/terraform.tfstate”
region = “eu-west-1”
dynamodb_table = “gc-tf-locks”
}
}

variables.tf

variable “genesyscloud_client_id” {
type = string
}
variable “genesyscloud_client_secret” {
type = string
}

- Switch to a remote backend immediately. Local state files break in GitHub Actions runners because the state isn't persisted between steps. S3 with DynamoDB locking prevents race conditions during parallel PR runs.
- Ensure your GitHub Actions workflow passes secrets directly to Terraform variables, not just env vars. The provider block must reference `var.genesyscloud_client_id`.
- Use Terraform Cloud workspaces if you want to avoid managing backend infrastructure yourself. It handles the OAuth token refresh and state locking natively.
- The 401 usually stems from the client ID not being passed correctly to the provider initialization. Verify the secret name in GitHub matches the variable name in `variables.tf` exactly. Case sensitivity matters.
- Split your pipeline. Run `terraform plan` on PR to generate the output comment, and `terraform apply` only on merge to main. This keeps your prod environment safe from accidental deployments.
4

Check your OAuth scope configuration. The suggestion above covers variable naming, but 401 Unauthorized often stems from missing admin:api or platform scopes in the client credentials. My gRPC service requires explicit scope validation to prevent silent failures. 1. Verify the OAuth client in Genesys Cloud has the correct scopes. 2. Use this curl command to test the token endpoint directly:

curl -X POST https://api.mypurecloud.com/api/v2/oauth/token \
 -H "Content-Type: application/x-www-form-urlencoded" \
 -d "grant_type=client_credentials&client_id=$ID&client_secret=$SECRET"

If this returns a valid token, your Terraform provider configuration is correct. If it fails, the issue is with the client setup. Token expiration is another factor. Ensure the token is refreshed before each terraform plan. My microservice handles this via a gRPC interceptor. You might want to implement a similar refresh mechanism in your CI/CD pipeline.

5

Here is a quick Guzzle script to validate your token and scopes before Terraform runs. It helps isolate if the issue is the client ID or the scope permissions.

$client = new \GuzzleHttp\Client(['base_uri' => 'https://api.mypurecloud.com']);
$response = $client->post('v2/oauth/token', ['form_params' => ['grant_type' => 'client_credentials', 'client_id' => $_ENV['GC_CLIENT_ID'], 'client_secret' => $_ENV['GC_CLIENT_SECRET']]]);

Check the scope field in the JSON response. You likely need admin:api or org:admin for Terraform provisioning. If the token is valid but the plan still fails, the scope is missing.

This bypasses the Terraform abstraction layer so you can see the raw OAuth error. It saves time debugging variable mapping issues in GitHub Actions.