canonical: https://jentic.com/apis/amazonaws.com/amazon-lex-runtime-v2

# AWS Amazon Lex Runtime V2

Jentic publishes the only available OpenAPI specification for Amazon Lex Runtime V2, keeping it validated and agent-ready. Lex Runtime V2 is the conversational dataplane for Amazon Lex V2 bots - it exchanges user text or audio with a deployed bot alias and returns recognised intents, slot values, and the bot's next response. The runtime carries session state across turns, supports both text and streaming utterance recognition, and is the integration point for chat widgets, IVR systems, and voice assistants built on Lex V2.

## For AI agents

Send user text or audio to a deployed Lex V2 bot and receive recognised intents, slot values, and the bot's next conversational response.

## Scope

Does not build or train bots, manage intents and slots at design time, or synthesise standalone speech - use for sending user utterances to a deployed Lex V2 bot and reading or overriding session state only.

## Capabilities

- Send a text utterance to a Lex V2 bot and receive intent, slot values, and response messages with RecognizeText
- Stream an audio utterance to a Lex V2 bot for speech-to-intent recognition with RecognizeUtterance
- Read the current state of a conversational session including recognised intents and active context with GetSession
- Set or override session state including slots, context, and session attributes with PutSession
- Delete a conversational session to reset state with DeleteSession
- Maintain per-user, per-locale, per-bot-alias session continuity across turns

## Use cases

### Text chatbot integration

Product teams use RecognizeText to wire a Lex V2 bot into a web chat widget or messaging integration. Each user message becomes a POST to /text with botId, botAliasId, localeId, and sessionId; the response includes the recognised intent, slot values, and the bot's outbound message - enough to render the next turn of conversation without managing dialogue state in the application.

Example prompt: Call RecognizeText with botId='ABC123', botAliasId='TSTALIASID', localeId='en_US', sessionId='user-42', and text='I want to book a flight to Paris', then return the recognised intent and slot values.

### Voice IVR and contact-centre integration

Contact-centre teams use RecognizeUtterance to stream caller audio to a Lex V2 bot and get back both the recognised intent and a synthesised audio response, all in one call. The runtime accepts standard PCM and Opus audio formats and returns the bot's reply as audio bytes plus structured intent data, which makes it the integration point for Amazon Connect IVR flows and other voice channels.

Example prompt: Stream an Opus-encoded user utterance to RecognizeUtterance for the customer-service bot alias and play the returned audio response back to the caller.

### Session state management for multi-turn flows

Application teams use GetSession and PutSession to inspect and override the dialog state mid-conversation - useful for hand-offs to human agents, prefilling slots from a CRM lookup, or steering the bot toward a specific intent based on user context. DeleteSession clears state at logout or session timeout. This makes Lex V2 sessions deterministic and inspectable rather than a black box.

Example prompt: Call PutSession to seed slot values customerName='Jane Doe' and accountId='987654' before the next user turn, then RecognizeText with the user's actual message.

### Agent-driven conversational flows through Jentic

AI agents that orchestrate hybrid LLM + Lex V2 flows use Jentic to call RecognizeText and PutSession without holding raw AWS credentials. Jentic stores keys in your Jentic One instance, signs each request with SigV4, and returns the structured intent and slot data - letting the agent decide whether to defer to Lex's deterministic intent matching or fall back to its own reasoning.

Example prompt: Search Jentic for 'send text to a Lex V2 bot', load RecognizeText, and execute against the support-bot alias with the user's last message, returning the recognised intent for downstream routing.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | /bots/{botId}/botAliases/{botAliasId}/botLocales/{localeId}/sessions/{sessionId}/text | Send a text utterance and receive intent and response |
| POST | /bots/{botId}/botAliases/{botAliasId}/botLocales/{localeId}/sessions/{sessionId}/utterance | Send an audio utterance and receive intent plus audio response |
| GET | /bots/{botId}/botAliases/{botAliasId}/botLocales/{localeId}/sessions/{sessionId} | Read current session state |
| POST | /bots/{botId}/botAliases/{botAliasId}/botLocales/{localeId}/sessions/{sessionId} | Set or override session state |
| DELETE | /bots/{botId}/botAliases/{botAliasId}/botLocales/{localeId}/sessions/{sessionId} | Delete a session and reset state |

## Key resources

- **Session** — A per-user, per-bot-alias, per-locale conversation context identified by sessionId
- **Intent** — The user goal recognised from an utterance, with confidence and slot values
- **Slot** — Named pieces of information collected from the user during dialog
- **Message** — The bot's outbound message in text or audio form
- **DialogAction** — The next dialog step Lex chose (ElicitSlot, ElicitIntent, Close, ConfirmIntent)

## Why Jentic

- **Setup:** Wiring Amazon Lex Runtime V2 by hand means implementing AWS SigV4 request signing, resolving the regional runtime-v2-lex host, streaming PCM or Opus audio to the utterance endpoint, and carrying session state across turns yourself. Through Jentic you install once, import Amazon Lex Runtime V2 from the API Directory, store your AWS access key and secret once, and your agent calls it.
- **Permission scoping:** Lex Runtime V2 puts botId, botAliasId, localeId, and sessionId in the URL path (/bots/{botId}/botAliases/{botAliasId}/botLocales/{localeId}/sessions/{sessionId}/text), so a rule can pin your agent to one bot alias and locale: it exchanges utterances for that alias and nothing else. You choose the operations it may call, so DeleteSession or PutSession state overrides are not included unless you add them.
- **Credential handling:** Your AWS access key and secret are stored once, encrypted, by your own Jentic One instance and each request is signed with SigV4 at execution time. They never enter the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'send text to a Lex V2 bot' or 'reset a Lex conversation session', and Jentic returns the matching Runtime V2 operation like RecognizeText or PutSession with its input schema so the agent calls the right endpoint without reading the AWS reference.

## Related APIs

- **Amazon Lex Models V2** — The build-time API for defining intents, slots, and bot versions that the runtime then serves
- **Amazon Polly** — Polly synthesises text-to-speech for bot responses when not using RecognizeUtterance's audio output
- **Amazon Lex Models V1** — The earlier Lex V1 modelling API - V2 is the current recommended platform

## FAQ

### Why is there no official OpenAPI spec for Amazon Lex Runtime V2?

AWS does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Amazon Lex Runtime V2 via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Amazon Lex Runtime V2 API use?

Lex Runtime V2 uses AWS Signature Version 4 HMAC signing with an access key ID and secret access key, optionally with a session token. Through Jentic, those credentials live in your Jentic One instance and the agent never handles raw secrets - Jentic signs each request server-side.

### Can I build or train a Lex V2 bot with the Amazon Lex Runtime V2 API?

No. The runtime is for sending utterances to an already-deployed bot alias and reading dialog state. Building intents, slots, and bot versions is done through the separate Lex Models V2 API (modelslexv2 in this catalogue) - runtime and modelling are split into two services.

### What are the rate limits for the Amazon Lex Runtime V2 API?

AWS publishes default soft limits per bot alias for RecognizeText and RecognizeUtterance, typically in the tens of TPS, with higher limits available on request. The exact numbers are not in the spec - check the AWS service quotas console for your account, and back off on ThrottlingException.

### How do I send a user message to a Lex bot through Jentic?

Search Jentic for 'send text to a Lex V2 bot', load RecognizeText, and call POST /bots/{botId}/botAliases/{botAliasId}/botLocales/{localeId}/sessions/{sessionId}/text with a JSON body containing the user's text. The response returns the recognised intent, slot values, and bot messages. Install with pip install jentic.

### How does Lex V2 maintain conversation context across turns?

Lex V2 keys conversation state on sessionId, scoped by botId, botAliasId, and localeId. As long as the client sends the same sessionId on each call, the runtime carries slots, dialog state, and session attributes across turns. Use GetSession to inspect the state and DeleteSession to reset it.

### Can I limit what my agent is allowed to do with the Amazon Lex Runtime V2 API?

Yes. Because you run Jentic One yourself, your own rules decide which Lex Runtime V2 operations and credentials the agent may use, and Lex puts botId, botAliasId, and localeId in the request path so a rule can pin the agent to a single bot alias and locale. You choose the operations it can call, so you can allow only RecognizeText and RecognizeUtterance for exchanging utterances while excluding PutSession state overrides and DeleteSession resets unless you explicitly add them. Your AWS access key and secret stay stored in your own Jentic One instance and are signed into each request at execution time, so the agent never handles the raw credentials.