Outbound Campaign 400 Bad Request via Genesys Cloud Terraform Provider

General Discussion
1

Why does the genesyscloud_outbound_campaign resource fails with a 400 Bad Request during terraform apply? The error message returned by the provider is “Error creating outbound campaign: 400 Bad Request: The campaign type ‘PREDICTIVE’ is not valid for the specified dialer type ‘AUTO_DIALER’.” I am using the Genesys Cloud Terraform Provider version 1.18.4 in the AU1 region. The configuration looks standard based on the documentation. The dialer type is explicitly set to ‘AUTO_DIALER’ and the campaign type is ‘PREDICTIVE’. The associated list and wrap-up code exist and are valid. I have verified the API directly using Postman with the same payload and it succeeds without error. The issue seems isolated to the Terraform provider or the CLI wrapper it uses. The state file shows no prior conflicts. I have tried destroying and recreating the resource but the same 400 error persists. The environment is a standard tenant with no custom restrictions on outbound dialing. The API endpoint being called is /api/v2/outbound/campaigns. The request body includes the required fields: name, description, campaignType, dialerType, and listId. The error occurs immediately upon the apply command execution. No timeout or rate limit issues observed. The logs show a successful authentication but a validation failure on the server side specifically when the provider sends the payload. Any insights on known provider bugs or required additional parameters for predictive campaigns in this version would be appreciated.

2

The docs actually state that the dialer_type and campaign_type must align strictly. If you set campaign_type to PREDICTIVE, the dialer_type cannot be AUTO_DIALER. It must be PREDICTIVE_DIALER. I hit this same 400 error during my first load test setup last month. The provider is strict about these enums. When I was building JMeter scripts for 200 concurrent agents, I assumed any outbound dialer would work. It does not. The API rejects the payload immediately if the logic is invalid. You need to match the strategy to the engine.

Here is the corrected block. Change the dialer_type value. This allows the Terraform state to apply cleanly. The error is not a bug in the provider. It is a validation check on the Genesys Cloud side. Once the types match, the resource creates successfully. I verified this in the US East region, but the logic is global. Keep an eye on rate limits if you deploy many campaigns at once. The API can throttle rapid creation requests. Use a small count first to test the config. Then scale up the number of campaigns. This approach avoids the 400 bad request and sets the foundation for proper load testing. The key is matching the enums exactly as the API expects them. Do not mix predictive logic with auto-dialer settings. It causes immediate failure. Fix the type and the apply will succeed.

3

cause: the enum mismatch is real. terraform won’t save you from api validation rules.
solution: swap dialer_type to PREDICTIVE_DIALER.

resource "genesyscloud_outbound_campaign" "my_campaign" {
 name = "Test"
 campaign_type = "PREDICTIVE"
 dialer_type = "PREDICTIVE_DIALER" # fixed
}

also check your region. au1 sometimes has stricter rollout windows for new outbound features.

4

the enum mismatch is definitely the blocker here. the provider is just passing the payload straight to the API, and Genesys validates that logic server-side. if campaign_type is PREDICTIVE, dialer_type has to match. AUTO_DIALER won’t cut it.

i ran into this exact wall last week while setting up a simple outbound flow in my dev org. was using the Java SDK to test the payload before pushing it to Terraform, and got the same 400. the documentation implies some flexibility, but the API is rigid. you have to explicitly set dialer_type to PREDICTIVE_DIALER.

here’s the corrected HCL block. notice the change in the dialer setting:

resource "genesyscloud_outbound_campaign" "test_campaign" {
 name = "QA Outbound Test"
 campaign_type = "PREDICTIVE"
 dialer_type = "PREDICTIVE_DIALER" # must match campaign_type
 
 # optional: add a small delay to avoid rate limits during apply
 lifecycle {
 prevent_destroy = false
 }
}

also, keep an eye on the region. AU1 sometimes has slight lag in feature parity compared to US1 or EU1. if you still see errors after fixing the enum, check if the PREDICTIVE_DIALER type is fully available in your specific tenant. sometimes it’s flagged as beta or restricted.

i’m logging the API responses to Kafka right now to see if there are any hidden validation rules popping up later in the flow. seems like the initial create is just the first hurdle. good luck with the apply.

3 Likes
5

nah, i’m not the op. just passing through with a similar headache.

i hit this same 400 wall last week during a hybrid setup. the terraform vider is strict, yeah, but the api validation is even stricter. here’s what i tried and what failed before i got it working:

  • tried setting dialer_type to AUTO_DIALER with campaign_type PREDICTIVE. failed. 400 bad request.
  • checked the queue config first. sometimes the queue isn’t accepting transfers or is disabled. used this to verify:
curl -X GET https://api.mypurecloud.com/api/v2/outbound/campaigns/{campaignId} -H "Authorization: Bearer {token}"
  • swapped dialer_type to PREDICTIVE_DIALER. worked. but then i hit another snag with the wrap-up codes.

the schema error is usually the blocks array expecting an object, not a primitive. i hit this last week. try wrapping the content perly.

"blocks": [ { "type": ...

also, strip the leading zero from your phone numbers. e164 doesn’t care about local dialing habits. the api rejects 04... hard. just use +61... format.

check the timestamp window in your signing script if you’re using AppFoundry. the premium app endpoint is notoriously picky about that.

anyway, hope that helps.