Add Webhook block

[baptisteArno]

Upvote & Fund

• We're using Polar.sh so you can upvote and help fund this issue.
• We receive the funding once the issue is completed & confirmed by you.

[wladiveras]

wait condition wont work when you use a input collect.

way to reply:
use a collect variable input and put a wait after that, wait will be skipped.

[ahsmha]

@baptisteArno is anyone working on this. if not can i take this up?

[vica-admin]

@baptisteArno This would be so useful! Would it be possible to fund this issue to speed up its development?

[laianeramos]

@vk-solutions-admin here's the link to fund https://polar.sh/baptisteArno/typebot.io/issues/1531

[vica-admin]

@laianeramos @baptisteArno Awesome, thank you for the flexibility!
I just funded the issue and will be available if you need any feedback about the feature.

[baptisteArno]

Thank you, can you tell us more exactly what is your use case so that I am sure we are talking about the same feature :)

[vica-admin]

@baptisteArno Sure, here are some feature requirements to give you an idea of what I was thinking about :)

Wait for Webhook

Goal

Enhance the bot's interactivity and responsiveness to external events, especially for human-in-the-loop flows.

Description

Implement a "Wait for webhook" feature that allows the bot to pause the conversation flow until a specified webhook is called. The output from the webhook should be usable in subsequent steps.

Requirements

1. [Must Have] Dynamic Webhook URL:

   • Users can input a variable "Webhook URL" to be dynamically assigned.

2. [Must Have] Flow Pause:

   • The bot should pause the conversation until it receives a response from the specified webhook.

3. [Must Have] Response Handling:

   • The output from the webhook should be parsed and made available for use in subsequent blocks.

4. [Nice to Have] Error Handling:

   • Optionally include error handling for webhook failures or timeouts, allowing users to define fallback actions.

5. [Nice to Have] Timeout Configuration:

   • Allow users to set a timeout duration for the webhook call, after which a predefined action can be executed.

6. [Nice to Have] User Notifications:

   • Optionally notify users that the bot is waiting for an external process (e.g., "Please hold on while we process your request").

7. [Nice to Have] Testing Mode:

   • Provide a testing mode for users to simulate webhook responses to validate flow behavior without actual calls.

8. [Nice to Have] Documentation:

   • Supply comprehensive documentation on the implementation and configuration of the "Wait for webhook" feature, including example use cases.

[baptisteArno]

I made good progress on that today, hopefully I will release a first version tomorrow 👌

[vica-admin]

Awesome news, thanks a lot!
Looking forward to testing it 🙌

[baptisteArno]

Figured a Wait block option would not be clear enough for new users so I decided to separate this logic in a new Logic block called "Webhook"

[abdullahbaa5]

Gonna deploy locally right away to try this out 👀

[baptisteArno]

@abdullahbaa5 For self-hosting, local testing here is the configuration of PartyKit to make it work: https://docs.typebot.io/self-hosting/configuration#partykit

[abdullahbaa5]

Seems to work as expected, Great job!

Questions/suggestions:

• Will there be a timeout implemented in the future? while having an ability to jump to a specific block in case of timeout, or some kind of failure handling
• Webhooks are dynamic, hence to be able to save the data json as string in a variable which one can later programmatically create a flow for different webhook responses.

Currently typebot is a step-by-step flow app, which is understandable.
However, typebot is now one step away from standing out from topping all the other bot builders, and that is the possibility of running two processes at once, for example:

[vica-admin]

Hello @baptisteArno, thanks for the awesome work on the Webhook block!
I tested it on Typebot Cloud and it works perfectly.

However, I'm unable to figure out how to deploy it using Docker-Compose as I already used "bun deploy" locally to get a unique Partykit host from packages/partykit and added it to the .env of my self-hosted deployment, but I still can't see the Webhook block in the list of blocks.

Could you please provide guidance for it?

[baptisteArno]

Did you set this env variable https://docs.typebot.io/self-hosting/configuration#partykit?

[vica-admin]

Yes, I added it to the .env and referenced it in the Docker-Compose. The Docker image used for the builder is baptistearno/typebot-builder:latest

[baptisteArno]

That's odd, are you sure you restarted the container after updating the .env file?

[vica-admin]

Yes I restarted the container and asked my DevOps provider to try it also on their side, but they had the same result.
Maybe it's not yet published in the latest Docker Image on DockerHub for the self-hosted version.

[baptisteArno]

Oh right, I am sorry, it is not yet released. We are doing a monthly release for self-hosting so it will be available on 1st of November

[MotazHakim]

it's not yet on self hosted , we are in December ! !!

[baptisteArno]

Yes, available https://docs.typebot.io/self-hosting/configuration#partykit

[vica-admin]

Hi @baptisteArno,

We’ve been testing the Webhook block extensively, and it works great as long as the Typebot window is in focus.

However, we noticed an issue when switching browser windows during the webhook listening phase. If we switch away and then back, it doesn’t seem to pick up the event sent by the third-party system to continue the flow.

For example:

• When Typebot is in focus, the "Commencer" button shows up correctly:
  
• If we switch browser windows while it’s waiting, the event doesn’t trigger the button to appear, even though it’s sent correctly:
  

Please let us know if this issue can be fixed, and we're ready to fund the fix since this is currently affecting heavily our use case.

[baptisteArno]

Can you create a new issue for this please? @vica-admin

[vica-admin]

Sure, here it is:
#1950