Agora + Avaya Experience Platform: Forward Detected Language → `speaker_locale`

Audience: Avaya Experience Platform (AXP) administrator or developer building a multilingual contact center flow
Time to integrate: ~20 minutes
Date: 2026-03-20

What this does

Avaya Experience Platform (AXP) Workflows expose a REST API task that lets you call external APIs mid-flow. If your AXP flow uses AI Virtual Agent language detection, IVR language selection, or Avaya's multilingual routing — you're already capturing the caller's language. Agora's speaker_locale session parameter accepts BCP-47 natively. Forwarding what AXP already knows unlocks precision temperature routing, improving confidence calibration by up to 13.5% ECE for native English speakers and up to 86% ECE for Germanic and high-T accent groups.

No extra language detection. No audio analysis. Just pass the signal AXP already has.

Integration

The pattern: at the start of your AXP Workflow, capture the detected language, then call Agora via a REST API task when creating the session.

Step 1: Capture language in your AXP Workflow

AXP surfaces caller language in a few common ways. Use whichever matches your setup:

Option A — AI Virtual Agent detection (recommended)
If you're running an Avaya AI Virtual Agent (Dialogflow or native), language is auto-detected and set as a workflow variable. Reference it directly.

Option B — IVR language selection
If callers press a digit to select their language (e.g. "Press 1 for English, 2 for Spanish"), map the DTMF input to BCP-47 inside the Workflow using a Set Variable task:

DTMF "1" → en-US
DTMF "2" → es-ES  
DTMF "3" → de-DE
DTMF "4" → ar-SA

Store the result in a workflow variable — e.g. detectedLocale.

Option C — Language-specific queue routing
If you already route callers to language-specific queues (e.g. Queue_German, Queue_Arabic), you can infer the locale from the queue name using a Decision task and store it as a variable before the REST call.

[Call Start]
    → [Language detection / IVR / queue routing]
    → detectedLocale = "de-DE"  (or however you're capturing it)
    → [REST API task: Create Agora Session]

Step 2: Add a REST API task to call Agora

In your AXP Workflow, add a REST API task (found under the Integration tasks panel) and configure it as follows:

Method: POST
URL: https://api.agora.ai/v1/sessions

Headers:

Authorization: Bearer {{YOUR_AGORA_API_KEY}}
Content-Type: application/json

Request body:

{
  "speaker_locale": "{{detectedLocale}}",
  "caller_phone": "{{flow.ani}}"
}

Step 3: Store the session ID and continue the flow

After the REST task succeeds, flow.agoraSessionId is available for all subsequent steps in the workflow.

Always configure the failure branch — a non-2xx from Agora should not break your call flow.

AXP CPaaS path (alternative)

If you're on Avaya OneCloud CPaaS rather than AXP Workflows, extract locale from IVR input or Dialogflow detection, then call Agora before returning your inboundXML response.

What Agora does with it

| Language detected in AXP | Agora routes to | ECE vs baseline | |--------------------------|-----------------|------------------| | en-US, en-GB, en-AU | T=1.0 (Native EN) | −13.5% | | de-DE, de-AT, nl-NL | T=2.0 (Germanic) | −86% | | ar-*, hi-IN, ur-PK | T=6.5 (High-T) | −84–85% | | anything else / null | T=4.0 (standard default) | baseline |

Unknown BCP-47 tags fall through to T=4.0 — no errors, no broken sessions.

Notes

speaker_locale is session-level. Set it once at session creation.
If locale is null, Agora defaults to T=4.0 — safe, no action required.
caller_phone (ANI) is optional — Agora can estimate from E.164 country code if locale is null (~80–85% precision for Native EN).
The REST API task in AXP supports retry config — recommend 1 retry with 500ms delay. Agora sessions are idempotent; retries are safe.

Questions? → agora docs or reach out directly.

Agora + Avaya Experience Platform: Forward Detected Language → speaker_locale