Conversations
Overview
Conversations are the primary interaction mechanism in EDDI. Each conversation represents a stateful dialog session between a user and a bot, maintaining complete history, context, and state throughout the interaction.
Key Concepts
Stateful Sessions: Each conversation maintains its own state (conversation memory) that persists across multiple interactions
Conversation ID: Unique identifier that references a specific conversation session
Lifecycle States: Conversations transition through states:
READY,IN_PROGRESS,ENDED,ERRORHistory Management: Full conversation history is maintained, with support for undo/redo operations
Context Passing: External context can be injected into conversations at any step
How Conversations Work in EDDI
When you create a conversation:
EDDI creates a new
IConversationMemoryobjectAssigns a unique conversation ID
Links it to a specific bot and user
Initializes the first conversation step
Returns the conversation ID for subsequent interactions
Each message sent to a conversation:
Loads the conversation memory from MongoDB/cache
Executes the bot's lifecycle pipeline
Updates the conversation memory with results
Saves the updated memory
Returns the bot's response
Time Travel Feature: EDDI has a powerful feature for conversations—the ability to go back in time using the
/undoand/redoAPI endpoints!
Working with Conversations
In this section we will explain how to send/receive messages from a Chatbot. The first step is creating a conversation. Once you have the conversation Id, you can send messages via POST requests and receive responses via GET requests, while having the capacity to send context information through the body of the POST request.
Creating/initiating a conversation :
Create a Conversation with a Chatbot REST API Endpoint
HTTP Method
POST
API endpoint
/bots/{environment}/{botId}
{environment}
(Path parameter):String Deployment environment (e.g: restricted,unrestricted,test)
{botId}
(Path parameter):String Id of the bot that you wish to start conversation with.
Response Model
Description of the Conversation response model
botId
(String) The id of the bot that sent the reply.
botVersion
(integer) The version of the bot that sent the reply.
userId
(String) The id of the user who interacted with the bot.
environment
(String) the name of the environment where the bot is deployed
conversationState
(String) The state of the current conversation, could be:
READY,
IN_PROGRESS,
ENDED,
EXECUTION_INTERRUPTED,
ERROR
redoCount
(integer) if undo has been performed, this number indicates how many times redo can be done (=times undo has been triggered)
conversationOutputs
(Array: <conversationOutput>) Array of conversationOutput
conversationOutput.input
(String) The user's input.
conversationOutput.expressions
(Array: <String>) an array of the expressions involved in the creation of this reply (output).
conversationOutput.intents
(Array: <String>) an array of the intents involved in the creation of this reply (output).
conversationOutput.actions
(Array: <String>) an array of the actions involved in the creation of this reply (output).
conversationOutput.httpCalls
(Array: <JsonObject>) an array of the httpCalls objects involved in the creation of this reply (output).
conversationOutput.properties
(Array: <JsonObject>) the list of available properties in the current conversation.
conversationOutput.output
(String) The final bot's output
conversationProperties
(Array: <>) Array of conversationProperty, <nameOfProperty> is a dynamic value that represents the name of the property
<nameOfProperty>.name
(String) name of the property.
<nameOfProperty>.value
(String|JsonObject) value of the property.
<nameOfProperty>.scope
(String) scope can be
step (=valid one interaction [user input to user output]),
conversation (=valid for the entire conversation),
longTerm (=valid across conversations [based on given userId])
conversationSteps
(Array: <conversationStep>) Array of conversationStep.
conversationStep.key
(String) the element key in the conversationStep e.g key : input:initial, actions
conversationStep.value
(String) the element value of the conversationStep e.g in case of actionq as key it could be an array string [ "current_weather_in_city" ].
timestamp.timestamp
(dateTime) the timestamp in (ISO 8601) format
Note
conversationPropertiescan also be used in output templating e.g:[[${properties.city}]].
Sample Response
The conversationId will be provided through the location HTTP Header of the response, you will use that later to submit messages to the Chatbot to maintain a conversation.
Example :
Request URL:
http://localhost:7070/bots/unrestricted/5ad2ab182de29719b44a792a
Response Body
no content
Response Code
201
Response Headers
Send/receive messages
Send a message
Send message in a conversation with a Chatbot REST API Endpoint
HTTP Method
POST
API endpoint
/bots/{environment}/{botId}/{conversationId}
{environment}
(Path parameter):String Deployment environment (e.g: restricted,unrestricted,test)
botId
(Path parameter):String Id of the bot that you wish to continue a conversation with.
conversationId
(Path parameter): String Id of the conversation that you wish to send the message to.
returnDetailed
(Query parameter):Boolean - Default : false
returnCurrentStepOnly
(Query parameter):Boolean - Default : true
Request Body
JSON Object , example : { "input": "the message", "context": {} }
The context here is where you pass context variables that can be evaluated by EDDI, we will be explaining this in more details in Passing Context Information
Example :
Request URL
http://localhost:7070/bots/restricted/5aaf90e29f7dd421ac3c7dd4/5add1fe8a081a228a0588d1c?returnDetailed=false&returnCurrentStepOnly=true
Request Body
Response Code
200
Response Body
Response Headers
Receive a message
Receive message in a conversation with a Chatbot REST API Endpoint
HTTP Method
GET
API endpoint
/bots/{environment}/{botId}/{conversationId}
{environment}
(Path parameter):String Deployment environment (e.g: restricted,unrestricted,test)
{botId}
(Path parameter):String Id of the bot that you wish to continue a conversation with.
{conversationId}
(Path parameter): String Id of the conversation that you wish to receive a the message from.
returnDetailed
(Query parameter):Boolean - Default : false
Example
Request URL:
http://localhost:7070/bots/unrestricted/5aaf90e29f7dd421ac3c7dd4/5add1fe8a081a228a0588d1c?returnDetailed=false
Response Body
Response Code
200
Response Headers
Time Travel: Undo and Redo
One of EDDI's most powerful features is the ability to go back in time within a conversation. The undo/redo functionality allows you to step backward and forward through conversation history, perfect for:
User Correction: User made a mistake and wants to retry
Testing: Developers testing different conversation paths
Debugging: Analyzing bot behavior at specific steps
User Experience: Allowing users to explore different options
How It Works
EDDI maintains a redo cache of undone conversation steps. When you undo a step, it's moved to this cache. You can then either:
Continue the conversation (clears redo cache)
Redo the step (restores it from cache)
Undo API
Check if Undo is Available
HTTP Method
GET
API Endpoint
/bots/{environment}/{botId}/undo/{conversationId}
Response
true if undo is available, false otherwise
Example:
Response:
Perform Undo
HTTP Method
POST
API Endpoint
/bots/{environment}/{botId}/undo/{conversationId}
Response
HTTP 200 (no content)
Example:
Response: HTTP 200 (No Content)
Effect: The last conversation step is removed from the conversation history and stored in the redo cache.
Redo API
Check if Redo is Available
HTTP Method
GET
API Endpoint
/bots/{environment}/{botId}/redo/{conversationId}
Response
true if redo is available, false otherwise
Example:
Response:
Perform Redo
HTTP Method
POST
API Endpoint
/bots/{environment}/{botId}/redo/{conversationId}
Response
HTTP 200 (no content)
Example:
Response: HTTP 200 (No Content)
Effect: The last undone step is restored from the redo cache and added back to the conversation history.
Complete Example Flow
Redo Cache Behavior
Important: The redo cache is cleared when you send a new message after an undo. This prevents inconsistent conversation states.
Checking Redo Cache Size
The conversation response includes redoCacheSize field:
redoCacheSize: 0- No undo has been performed, redo not availableredoCacheSize: 1- One undo performed, one redo availableredoCacheSize: 2- Two undos performed, two redos available
Use Cases
1. User Correction
2. Exploring Options
3. Testing Bot Behavior
Limitations
Undo/redo only affects conversation history and memory
External API calls made during undone steps are not reversed
Example: If a payment API was called, undoing won't refund the payment
Redo cache has a size limit (configurable)
Redo cache is session-specific (cleared on conversation end)
Best Practices
Always check availability before calling undo/redo to avoid errors
Inform users when undo clears redo cache (UX consideration)
Be careful with side effects - undo doesn't reverse external API calls
Use for user convenience - great for conversational UX
Log undo/redo - helps with analytics and debugging
Related API Endpoints
POST /bots/{environment}/{botId}- Start conversationPOST /bots/{environment}/{botId}/{conversationId}- Send messageGET /bots/{environment}/{botId}/{conversationId}- Get conversation statePOST /bots/{environment}/{botId}/undo/{conversationId}- Undo last stepPOST /bots/{environment}/{botId}/redo/{conversationId}- Redo last stepGET /bots/{environment}/{botId}/undo/{conversationId}- Check undo availabilityGET /bots/{environment}/{botId}/redo/{conversationId}- Check redo availability
Sample Bot
Last updated
Was this helpful?