Platform API 422 on nice_cxone_authentication sso_enabled binding in provider 1.19.6

The 03:00 JST compliance sync job choked on the nice_cxone_authentication resource again. Pipeline is stuck. Terraform 1.9.8 paired with nice-cxone 1.19.6 throws a 422 Unprocessable Entity. State backup shows the sso_enabled flag is already true in the remote state. Provider is doing jack all on the drift detection though. Refuses to acknowledge the mismatch without a full destroy-and-recreate. Non-starter for a prod org.

Raw API response via Postman shows the /api/v2/authentication endpoint accepts the payload fine when the oauth_scopes array includes admin:users:read. Provider is stripping the scope silently during the plan phase. Debug logs confirm this behavior. 2024-05-21T03:05:12Z timestamp shows the request body missing the scope entirely.

Pinning the provider to 1.19.5 yields the same 422. Rolling back the Terraform state to the 02:00 JST snapshot doesn’t help. Apply still fails. State drift isn’t the issue here. It’s the request construction.

What’s the correct way to force the oauth_scopes through the nice_cxone_authentication resource without triggering the 422? Manual API calls work. Terraform won’t hold the config.

resource "nice_cxone_authentication" "corp_sso" {
 sso_enabled = true
 idp_metadata_url = "https://idp.corp.example.com/metadata"
 oauth_scopes = ["admin:users:read", "admin:users:write"]
 // provider drops oauth_scopes here
}

Debug logs attached. Scope array is empty in the JSON payload sent to the platform.

Is the state file actually pointing to the correct org ID? Try forcing a refresh with terraform refresh to see if the provider picks up the remote sso_enabled value before attempting the apply.