Druid Generic Chat

The Druid Generic Chat channel provides a REST API-based integration that connects your proprietary web chat interface directly to the Druid Conversational Engine.

The Custom Web Chat channel is the preferred choice for organizations that want to leverage the Druid Conversational Engine while retaining complete ownership of the web chat interface and overall user experience.

Unlike the standard Druid Web Chat channel, which includes a ready-to-use chat widget and user interface, the Druid Generic Chat channel does not provide any front-end components. Instead, it exposes a set of REST messaging endpoints that enable your application to exchange text messages with a Druid AI Agent while giving you complete control over the user experience.

Interaction Mechanisms

The Druid Generic Chat channel supports two distinct communication mechanisms to facilitate message exchanges between your custom front-end interface and the Conversational Engine. Depending on your system design and responsiveness criteria, you can implement either a synchronous approach or an asynchronous polling cycle to manage the user experience.

Synchronous Request-Response (Default)

In this mode, when a user sends a message through your proprietary chat UI, your backend client API forwards this input to Druid by calling the message delivery REST API (/messages). Your client API holds the HTTPS connection open with Druid while the Flow Engine processes the request. Once ready, all generated AI Agent replies are delivered back to your client API in the synchronous response payload, which then routes them back to the front-end interface.

NOTE: If a flow step triggers a slow external API or data operation, the client application must wait until the full processing cycle completes, which can lead to visible delays in the user experience.

Long Polling Mechanism (Asynchronous)

Long Polling offers an asynchronous alternative to the default synchronous request-response model. It is designed to significantly improve responsiveness and user experience, especially in scenarios involving multi-message replies or delayed AI Agent processing (for example, due to complex backend integrations, database lookups, or proactive messages).

In this mode, when your backend client API transmits a user message to Druid via the REST messaging API (POST *.druidplatform.com/api/generic-chat/{botId}/messages), it does not wait for a direct synchronous response from the Flow Engine. Druid acknowledges receipt immediately with a fast confirmation payload and closes that initial connection.

Immediately after submitting the message, your backend client API initiates a continuous polling mechanism by making repetitive POST requests to the dedicated Long Polling endpoint: POST *.druidplatform.com/api/generic-chat/{botId}/messages/getMessages.

Druid holds these connections open until a AI Agent message or event becomes available. As soon as a message is ready, Druid sends it back to the client REST API, closing that specific /getMessages request. Immediately after that, the client REST API will initiate a new request to fetch the next message from the AI Agent, and will continue to do so, until the chat session closes.

This asynchronous approach ensures that messages are delivered to the user as soon as they are generated by Druid, without waiting for an entire set of responses or for a slow integration to complete.

The /getMessages request will time out after a set period (typically 30 seconds) if no messages are available, at which point the client REST API must immediately re-initiate the getMessages call to continue polling.

The following sequence outlines how your backend client API handles communication between your custom front-end interface and Druid when using the long polling asynchronous model:

  1. Initiating the conversation:
    1. When the user opens the web chat, the web chat interface initiates the conversation with the client REST API.
    2. The client REST API initiates the conversation with Druid AI Agent, which authenticates the conversation.
    3. The Druid AI Agent responds with the Welcome Message.
  2. The Web chat sends the welcome message:
    1. The client REST API responds with the Welcome Message (received from Druid AI Agent).
    2. The web chat interface gives the Welcome message to the user.
  3. The web chat interface captures user input:
    1. The web chat interface captures the “User says”.
    2. The web chat interface sends the user's messages to the client REST API .
    3. The client REST API sends the user input to the AI Agent, calling the Druid API Create Activity (POST *.druidplatform.com/api/generic-chat/{botId}/messages).
    NOTE: The client REST API DOES NOT wait for a synchronous response from this API call.
  4. Backend client API polling for AI Agent responses:
    1. Immediately after sending the user's input, the backend client API begins polling for responses by making periodic POST requests to the Long Polling endpoint: *.druidplatform.com/api/generic-chat/{botId}/messages/getMessages.
    2. The Druid AI Agent sends available AI Agent responses to the backend client API via these getMessages calls, as soon as they are ready. Each getMessages call returns one message/event.
    3. If the Druid AI Agent has more messages, the backend client API immediately makes another POST request to getMessages to retrieve the next one. This continues until no more messages are received.
  5. User closes the call:
    1. The web chat UI announces the backend client API that the conversation is closed.
    2. The backend client API announces the Druid AI Agent that the conversation is closed (e.g., by sending a close_conversation message) to end the active long polling loop and free up system resources.

Channel Configuration

NOTE: For Druid on premise deployments, make sure that you provide inbound access from the following messaging endpoint: DRUID.BotApp.

The Druid Generic Chat channel is active by default in Druid.

To configure the channel:

  1. In the Druid Portal, go to your AI Agent Settings, and click the Channels tab.
  2. Search for 'Druid Generic Chat' and click on the card.
  3. Copy the generated Authorize URL and AI Agent URL.
  4. If your system architecture requires asynchronous delivery, toggle the Enable long polling option and copy the corresponding long poll endpoint.
  5. Optionally, customize channel display settings as follows:
    • Alias: Enter a clear, business-friendly display name (e.g., Interactive Messaging). This value is stored in[[ChatUser]].ChannelDisplayName, which appears in reporting tools like AI Agent Summary dashboard - Engagement KPIs and can also be referenced in flow business logic.
    • Description: Enter a brief description. This is particularly helpful when using an alias, as it helps identify the channel's specific purpose within the Druid Portal.
    • Channel Icon: Upload a custom icon to display on the channel card within the Druid Portal.
  6. Click Publish to activate the channel.

During session execution, Druid automatically populates the following system fields:

  • [[ChatUser]].ChannelId = "generic-chat"
  • [[ChatUser]].ChannelDisplayName - Stores the Alias which is used in AI Agent Summary Dashboard > Engagement KPIs > Channel chart.
  • [[ChatUser]].UserId - Stores the unique client user identification string.

Druid API Reference

Use these specifications to connect your proprietary interface application layer to the Druid messaging engine.

Authorize

Establishes an anonymous session and provides the short-lived access token required for subsequent interactions.

Syntax

POST: *.druidplatform.com/api/services/app/Chat/AuthorizeAnonymousAsync

Request Body

Copy

Authorize API

{
   "botId": "<bot_id>",
   "queryString": "phone=<phone>",
   "channelId": "generic-chat"
}

Response

Copy

Response Example

{
   "botId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
   "userId": "string",
   "conversationId": "string",
   "token": "string"
}

The returned bearer authorization token remains valid for exactly 1 hour from generation time.

Send Messages (Create Activity)

Transmits the text written by the user to the Druid messaging layer.

Syntax

POST: *.druidplatform.com/api/generic-chat/{botId}/messages

Request Header

In the request header, map the Authorize key to the bearer token obtained from the Authorize API. Use the Druid-specific CONCAT function for the Authorize key value with the following syntax:

Copy

Authorize value mapping

CONCAT('Bearer ',[[Entity]].StringField)

Here, [[Entity]].StringField represents the field that stores the token obtained from the Authorize API.

Request

Copy
Request template
{
      method: "POST",
      headers: {
        Authorization: `Bearer ${session.token}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({
        type: "message",
        channelId: "generic-chat",
        conversation: {
          id: conversationId,
        },
        from: {
          id: userId,
        },
        text: message,
        attachments,   // sending files for file upload steps
        timeout: 50,
      }),
    }

The timeout parameter enables you to specify a duration in seconds for the system to wait for a response from the Flow Engine. If the Flow Engine doesn't respond within the configured timeout period, the system will log an error in the Conversation History.

Response

Copy
{
    "type": "message",
    "channelId": "generic-chat",
    "conversation": {
            "id": "<conversationId>"
    },
    "to": {
            "id": "<userId>"
    },
    "text": "<AI Agent response>",
}

Get Messages (Long Polling)

Retrieves messages asynchronously from the Druid AI Agent when the background long polling mechanism is enabled

Syntax

POST *.druidplatform.com/api/generic-chat/{botId}/messages/getMessages

Request Header

In the request header, map the Authorize key to the bearer token obtained from the Authorize API. Use the Druid-specific CONCAT function for the Authorize key value with the following syntax:

Copy

Authorize value mapping

CONCAT('Bearer ',[[Entity]].StringField)

Here, [[Entity]].StringField represents the field that stores the token obtained from the Authorize API.

Request Body

Copy
{ 
  "conversationId": "your-conversation-id" 
} 
Parameters
Parameter Type Description Required
conversationId String The unique identifier for the ongoing conversation, obtained from the Authorize API response. Yes

Response

The response structure for getMessages is identical to the Responds with Message sections described for SendMessages API response, containing the AI Agent response or an event.

NOTE: The getMessages endpoint will return the next available message or event as soon as it's ready, or after a timeout period if no message is available. The client API should continuously poll this endpoint until the conversation is officially closed.

Request body examples

Response Payload

Responses are fetched using long polling (/getMessages).

The following provides supported flow steps and their supported features.

Channel Capabilities

  • Session Management. Sending "reset" clears the active flow state while keeping the active conversationId intact.

  • Multi-file Upload. Multiple file attachments can be sent in a single incoming payload.

  • Live Agent Escalation. Native handoff to human helpdesk agents is fully supported.