CXone client_credentials grant returning 401 in terraform local-exec

NICE CXone API & Integrations
1

My config is not working…

HTTP 401 Unauthorized

i’m trying to spin up a terraform local-exec that hits the CXone /api/v2/authorization/oauth2/token endpoint with a client_credentials grant. the json payload is just {"grant_type": "client_credentials", "client_id": "abc123", "client_secret": "xyz789"} and the org settings definitely match. curl requests don’t return a token, and the platform docs don’t mention any extra headers. still throwing the same 401 from my tokyo workstation.

2

It depends, but generally…

Error: 401 Unauthorized
The issue is likely the content-type header or how the secret is encoded. cxone expects application/x-www-form-urlencoded for the token endpoint, not json. sending a json body usually breaks the oauth handler.

try switching the request format. also, make sure the client secret isn’t url-encoded incorrectly in terraform. i ran into this when moving from aws terraform to genesyscloud. the provider handles auth differently than standard http requests.

use this payload structure instead:

{
 "grant_type": "client_credentials",
 "client_id": "abc123",
 "client_secret": "xyz789"
}

wait, that’s still json. my bad. you need form data.

grant_type=client_credentials&client_id=abc123&client_secret=xyz789

set the header to Content-Type: application/x-www-form-urlencoded. if that fails, check if the app registration has the correct scope. usually it’s urn:nice:cxone:platform:api. missing scopes cause 401s too.

3

gotcha is usually the Content-Type. as As noted above, the oauth endpoint is strict about application/x-www-form-urlencoded. if you’re sending json, it fails silently or throws a 401 because the parser doesn’t find the expected keys.

here’s a quick go snippet that handles the encoding properly. you can adapt this for your terraform script or just test it locally to verify your creds before wiring it into the infra.

package main

import (
	"fmt"
	"net/http"
	"net/url"
	"strings"
)

func getAccessToken(clientID, clientSecret, env string) (string, error) {
	baseURL := fmt.Sprintf("https://api.%s.genesyscloud.com", env) // e.g., us-east-1
	tokenURL := fmt.Sprintf("%s/api/v2/authorization/oauth2/token", baseURL)

	data := url.Values{}
	data.Set("grant_type", "client_credentials")
	data.Set("client_id", clientID)
	data.Set("client_secret", clientSecret)

	req, err := http.NewRequest("POST", tokenURL, strings.NewReader(data.Encode()))
	if err != nil {
		return "", err
	}

	// this is the critical part. many people forget this or set it to json
	req.Header.Set("Content-Type", "application/x-www-form-urlencoded")

	client := &http.Client{}
	resp, err := client.Do(req)
	if err != nil {
		return "", err
	}
	defer resp.Body.Close()

	if resp.StatusCode != http.StatusOK {
		return "", fmt.Errorf("oauth error: %s", resp.Status)
	}

	// parse body for access_token...
	return "token", nil
}

if you’re doing this in terraform, make sure the client_secret isn’t getting escaped weirdly by the provider. sometimes the $ or special chars in secrets break the shell execution. i usually write the creds to a temp file and read them in to avoid shell injection issues.

4

thanks for the hint about the content-type. switched the terraform local-exec to use --data-urlencode instead of posting json and it’s working now.

the oauth endpoint definitely needs application/x-www-form-urlencoded. sending json body was the blocker. here is the working curl command i used in the local-exec for reference.

resource "null_resource" "test_auth" {
 provisioner "local-exec" {
 command = <<EOT
 curl -X POST https://api.mypurecloud.com/api/v2/authorization/oauth2/token \
 -H "Content-Type: application/x-www-form-urlencoded" \
 --data-urlencode "grant_type=client_credentials" \
 --data-urlencode "client_id=${var.cxone_client_id}" \
 --data-urlencode "client_secret=${var.cxone_client_secret}"
 EOT
 }
}

good to go.

5

Switching to --data-urlencode is definitely the move here. The OAuth endpoint is picky about that format, like a vending machine that only accepts exact change and rejects digital wallets.

If you’re keeping this in Terraform, just be careful with how you pass the secret. Terraform loves to escape characters in strings, and that can mess up the encoding if you’re not careful. It’s usually safer to put the credentials in a file or use a variable block rather than hardcoding them in the local-exec command. Keeps the logs cleaner too.

One thing to watch out for is the token expiry. These credentials grant tokens don’t last forever. If your local-exec runs again later, you might hit a 401 just because the old token expired and you didn’t refresh it. The genesyscloud provider handles this auth dance for you, so if you’re doing more complex provisioning, it’s worth looking at the provider’s auth configuration instead of rolling your own curl commands. Saves a lot of headache down the line.