When your chatbot connects to an external service, it uses a webhook block to send a request to that service’s API. Now imagine the service takes too long to respond. What should your chatbot do? Wait forever? Give up too early?
That’s exactly what the Request Timeout setting in the webhook block controls.
It allows you to decide how long the webhook should wait for a response before it times out and moves on. Setting it correctly ensures that your chatbot remains fast, responsive, and user-friendly, even when external systems are slow or unresponsive.
What is Request Timeout?
Request Timeout is a setting in the Webhook block that determines how long (in seconds) your chatbot should wait for a response from the API it’s calling. If no response is received within the time limit, the request is automatically stopped or timed out.
Without this timeout setting, your chatbot might feel stuck, slow, or unreliable, especially when the external API is delayed.
How does it work?
Inside the Webhook block, you’ll find an option to set the timeout duration. This can be anywhere from 5 to 40 seconds.
Here’s how to decide the right timeout value:
- Set a lower timeout for fast, reliable APIs (5–10 seconds). For example, if you’re querying a customer database, it usually replies quickly.
- Go higher for slower APIs (up to 40 seconds). For example, if you’re triggering a background process like generating a report or checking billing status from a legacy system.
Once the time you set has passed and the API hasn’t responded, the request is cancelled and the webhook path is considered a failure. You can then use Multipath to handle this timeout scenario, such as showing an apology, offering a retry button, or escalating to a human agent.
Why is Request Timeout important?
Setting a request timeout is not just a technical detail; it’s about improving your overall customer experience.
Here’s why it matters:
- Keeps conversations responsive.
- If the bot waits too long, users might think it’s broken or ignoring them. Timeout settings ensure the bot doesn’t keep them hanging.
- Prevents wasted resources.
- Gives you control.
- You get to choose how patient your bot should be — depending on the reliability of the external system.
- Enables fallback paths.
- When a timeout happens, you can guide the conversation intelligently. For example, “Looks like that took too long. Want me to try again?”
Example Use Case
Let’s say your webhook block is calling an order management system to check the status of a recent purchase.
If the API typically responds in 2 seconds, you could set the timeout to 7 seconds, giving it some buffer, but not too much.
Now:
- If the response comes within 7 seconds, the bot proceeds to show the order status.
- If not, then the request times out, and the bot can show:
- “Sorry, this is taking longer than expected. Would you like to try again or talk to an agent?”
This keeps the user informed, avoids frustration, and adds a touch of professionalism.
Best practices for setting Request Timeout
- Don’t leave it at the default blindly. Think about the specific system your webhook is calling.
- Talk to your developers or backend team to understand average response times.
- Start with 10–15 seconds if unsure, then adjust based on real usage and feedback.
- Pair with Multipath for graceful handling of timeouts (e.g., 504 Gateway Timeout response).
Technical notes:
- The URL and Connection fields are mandatory in a Webhook block. They define where the request goes and how it’s authenticated.
- Optional fields (like Headers, Query Parameters, or Request Body) depend on the API you’re calling. Use them only if needed.