https://discord.gg/botpress logo
API like Voiceflow
# šŸ‘€feature-requests
l
Agree. It would be extremely useful.
f
l
Not exactly. The current approach requires you to take active steps to get the bot response. What would be convenient is to have an endpoint to which you send a a request and get bot's reply as a response. Right now it is only possible via an additional custom app acting as an intermediary layer: it gets the request, forwards it to the bot, then acting as a webhook, catches bot's response and returns it as a response to the initial request.
c
I wanted to share my current method for handling API responses in Botpress and get your feedback on whether this is the right approach. Here’s how I’m doing it: 1. For apps that don’t integrate with Botpress (e.g., Smartsuite): - I use MAKE to send data (including the conversation ID) from Botpress to the app. - Once the app records the data, it sends a confirmation back to MAKE via a webhook. - MAKE then forwards this confirmation to Botpress using Botpress events. - Finally, Botpress uses the event to reply with a confirmation message to the user. 2. For apps that integrate with Botpress: - I use a Botpress template to send data directly to the app. - Similar to the first method, I use MAKE to handle the confirmation from the app and send it back to Botpress via a webhook. - Botpress receives the confirmation through an event and replies to the user. Do you think this is the right way to handle API responses? Are there any improvements or alternative approaches you’d recommend?
f
Setting up a listener for the conversation ID is quite easy. I used Botpress Chat to replay some conversations in our new bot and then saved the results. What I’m curious about is whether you’ve tried the Chat API/integration, and if so, what exactly is preventing you from using it for your use case? I can share the part of the script that used it if you’d like. It’s a bit messy since we only needed to do it once, but you could probably use Claude or another model to refactor the code for better readability.
a
No because this will need a webhook where the message from the bot will be sent instead of it being in the api response.
f
It does not need a webhook. It is optional.
"Webhook URL: This URL is entirely optional."
c
@fresh-fireman-491 Can you please share use case
f
I used the Botpress Chat integration to replay some conversations in our new bot and then saved the responses, so we could compare our new bot to our previous bot.
a
So where will the message of the bot be sent then? (Hint: It's not in the api response)
f
The Chat API offers two ways of listening to chat events in real time: Server-Sent Events, which is the standard way. Webhooks, or HTTP callback URLs. Server-Sent Events To listen to chat-related events on an SSE stream, you must call the listenConversation operation. This operation will open an SSE stream that you can listen to.
All of the information can be found in the documentation https://botpress.com/reference/introduction
a
@fresh-fireman-491 I tried making a call to the listenConversation endpoint but it returns a blank 200 response. So how exactly do I get the bot's message?
f
This is the code that I quickly put together for our one time use.
It should give you some more knowledge about what I did. If you have any specific questions about it let me know,
a
Had ChatGPT look into the code and it said there was no SSE stream? So I'm assuming you were using webhooks which is what I was exactly pointing out. ChatGPT: Based on the code you shared, there’s no indication that it sets up a Server-Sent Events (SSE) stream. The file imports modules like a client pool and a message adapter, and then defines a function (replayConversation) that retrieves a Botpress client and (presumably) makes an API call to replay a conversation. However, there’s no evidence of creating an EventSource (or any similar SSE mechanism) or wiring up any onmessage/onerror handlers that are typical for SSE streams. For context, Botpress does provide an SSE-based endpoint (often called ā€œListen Conversationā€) to receive messages and events in real time (see ). But in this file, the logic appears to be geared toward sending a set of messages and awaiting a complete reply—using a standard API call rather than setting up a continuous stream. If you were expecting SSE functionality, you might need to look at a different part of the codebase where the Botpress Chat API is used to listen to live conversation updates. In this snippet, however, the focus is on retrieving a client from the pool and likely performing a one-off replay call without SSE streaming.
g
Hi @adamant-glass-32780, I’m facing similar issues, i wonder if you have solved it yet? Thanks!
3 Views