Does anyone know why IVR flow fails with 400 on language detection?

Has anyone figured out why the IVR flow fails with a 400 error during language detection? In Zendesk, we just set the locale, but Architect seems stricter. Here are the steps:

1. Create a new IVR flow.
2. Add a Language Detection block.
3. Save and test.

The error says ‘Invalid language code’. We are using ‘fr-FR’. Is the format different in Genesys?

If I remember correctly…

Genesys expects the ISO 639-1 code alone, like fr, not the full BCP-47 tag.

Drop the region suffix and retry the save.

This is caused by a misalignment between the Architect block configuration and the specific locale validation rules enforced by the Speech Analytics service. While the ISO 639-1 code is technically valid for basic routing, the Language Detection block often requires the full BCP-47 tag when integrated with advanced transcription or sentiment analysis features. Using just fr may trigger a fallback to a default model that lacks the necessary phonetic data for your specific use case, resulting in the 400 error.

The configuration should match the exact language profiles available in the Genesys Cloud marketplace. Verify the supported languages in the Admin console under Speech Analytics settings.

Ensure the flow logic explicitly defines the fallback path if the confidence score is low. This prevents the system from throwing an unhandled exception. The dashboard metrics will reflect these interactions under the “Speech Analytics” section, allowing for better monitoring of detection accuracy.

The problem here is…

Does anyone know why the IVR flow fails with a 400 error during language detection?

Confirmed. Switching from fr-FR to fr resolved the 400 error. The Architect block seems strict on format. I updated my JMeter script to match this config. Load testing passes now without handshake failures.

This is a classic validation mismatch between the UI expectation and the underlying API contract. The 400 error is not about the language support itself, but about the strict schema validation on the language attribute within the genesyscloud_flow resource.

When defining the language detection block in Terraform, the provider expects the base ISO 639-1 code. Using the full BCP-47 tag (like fr-FR) often triggers a 400 Bad Request because the backend parser for this specific node type does not accept the regional suffix in the initial configuration payload.

Here is the correct HCL structure that avoids this error:

resource "genesyscloud_flow" "ivr_flow" {
 name = "IVR-Lang-Detect"
 description = "Flow with language detection"
 enabled = true

 flow {
 entry_point_ref = "start"

 nodes {
 id = "start"
 type = "start"
 name = "Start"
 exit_nodes {
 node_ref = "lang_detect"
 }
 }

 nodes {
 id = "lang_detect"
 type = "languageDetect"
 name = "Detect Language"
 settings {
 language = "fr" # Use base code only
 # Do not use "fr-FR" here
 }
 exit_nodes {
 node_ref = "end"
 }
 }
 }
}

The key is keeping the language setting minimal. If you need to route based on region later, handle that in the subsequent routing block after detection, not in the detection node itself. This aligns with how the GC CLI handles exports too.

Note: Ensure your environment has the French language pack enabled in the Speech and Text settings before applying this flow, or the runtime will fail even if the config applies successfully.