Notifications
Clear all
How To
2
Posts
2
Users
0
Reactions
6
Views
Topic starter
The concept is:
Making the Response to Webhook function without timing out.
My use case:
I have several applications that trigger workflows via a webhook. At the conclusion of a workflow, I want to send specific fields, such as a URL or generated data, back to the originating application. However, there appears to be a timeout issue. The workflow itself can take up to 5 minutes, as we are making calls to different API endpoints, for instance, to generate images or conduct in-depth research.
Unfortunately, we receive the webhook response before the workflow has completed. Consequently, we can only process the initial webhook response, not the one we intend to receive, which is defined in the Respond to webhook node.
I observed that it was possible to implement a delay function when hosting callin.io locally. However, we are currently using the browser-based version.
It would be highly beneficial if the webhook response would wait until the process is truly finished, rather than responding prematurely. This would make the configuration in the initial webhook (respond to webhook node) fully functional.
I think it would be beneficial to add this because:
The respond through respond to webhook node setting would function correctly.
Any resources to support this?
Not really. Just hoping that we can find a solution.
Are you willing to work on this?
Anything I can do to help, please let me know.
Posted : 17/03/2025 12:13 pm
Hi Clemens,
I've encountered a similar constraint with the Respond to Webhook node, particularly in workflows involving lengthy tasks such as external API calls, image generation, or AI processing.
By default, the webhook timeout in callin.io cloud (and even self-hosted configurations) is restricted – I believe it's approximately 2 minutes for webhook responses. If your workflow exceeds this duration, the initial webhook request will time out, and the client will receive no response or an incomplete one.
Workaround I use in production:
- Split the workflow into two distinct parts:
- Part 1: Utilize a Webhook (no response) → store the data → trigger Part 2 using
Execute Workflow(asynchronously). - Part 2: Handle the intensive processing and then send the outcome to a callback URL (provided by the client).
- If a callback is not feasible:
Employ aWaitnode or a polling mechanism integrated with a frontend to monitor the status, rather than maintaining an open connection.
Why “Respond to Webhook” has limitations:
The node technically does wait, but only within the constraints of HTTP timeouts. Beyond these limits, you are constrained by browser/client behavior and server configurations.
Suggestion for the callin.io team:
It would be beneficial to have:
- An explicit “hold response open” mode that queues the response until a
Finishtrigger is activated. - A built-in method to extend the timeout in the cloud version (or at the very least, clearly document the existing limit).
Let me know if you would like a functional example or a template demonstrating the split setup I've described; I'd be happy to share it.
Posted : 15/05/2025 5:12 am