The Terraform apply is returning a 400 error during the update of the web deployment. It’s not clear why the promotion is failing.
resource "genesyscloud_web_deployment" "prod_deployment" {
name = "Production_Web_Deployment"
deployment {
endpoint = "https://webapp.example.com"
allowed_domains = ["example.com"]
}
}
The call to /api/v2/webdeployments/deployments/{deploymentId} is failing.
{
"message": "Bad Request",
"code": 400,
"status": "error"
}
PureCloudPlatformClientV2 presented us with a nearly identical 400 error during a deployment cycle back in 2021. We were attempting to automate our web deployment updates via the cxascode provider when the process began failing intermittently during the promotion phase. The initial investigation suggested a network timeout, but the reality was far more tedious.
It was discovered that the PUT /api/v2/webdeployments/deployments/{deploymentId} call was rejecting the payload because of a mismatch in the configuration object. Specifically, certain fields that were read-only after creation were being passed back into the update request by Terraform. The API doesn’t just ignore these fields; it returns a 400 Bad Request.
To resolve this, we had to refine our Terraform resource block to ensure we weren’t attempting to “update” immutable properties. If the configuration is being managed as a variable, ensure the deployment body doesn’t include stale metadata.
resource "genesyscloud_web_deployment" "example" {
name = "Production-Deployment"
# Ensure only mutable fields are defined here
# Avoid passing the full object returned from a GET call
configuration {
# specific config settings
}
}
The resolution involved implementing a strict schema check to strip out the read-only attributes before the apply phase. Once the payload was cleaned of those immutable fields, the 400 errors vanished. It’s a peculiar nuance of how the provider handles state for web deployments compared to other resources.
PUT /api/v2/webdeployments/deployments/{deploymentId}
{
"name": "Updated Deployment",
"domain": "webapp.example.com"
}
The earlier reply is spot on. A 400 often means the payload is MISSING a required field during the PUT. Double check the schema against the actual deployment object. Be careful with rate limits on these calls to avoid 429s during CI/CD runs. Always use a service account with minimal scopes for these updates.