Webhook Endpoint response time: Need to return 200 BEFORE finishing the rest of the workflow


I’ve come across a very aggravating behaviour of API Workflows. I am receiving Webhooks from a third party (I don’t have control over the format or behaviour of their requests). This third party will treat a webhook as failed if they do not receive a response within 10 seconds. As a consequence, they will send a second webhook with the same information a few minutes later (big problem for my app, because the workflows take about 20 seconds).

What I did was natural:

Return a 200 response right away - so that I can do processing in the background and the third party knows that I successfully received their request.


Bubble will only return the data from API (a 200 response) AFTER all the workflows have completed… FACEPALM

What then, I ask, is the point of letting me return data from API as an action (that can be placed more than once) if I don’t have any control of what’s going on? Very frustrating …

Ah well.

Does anyone have a solution for this? I can’t use another API Workflow, because I really need the body of the API call to remain intact since I am authenticating the call manually.

Thank you!

We have offloaded our webhook monitoring to AWS for this reason amongst others - a Gateway endpoint connected up to a Lambda that then sends what we need over to Bubble;

Another approach that works - but just inside of Bubble - is creating a database table (payload_temp or similar) and set the datatype of a field to the API schema for the webhook. When your monitoring endpoint is hit, you create a db object with the payload object and then pass it off to another endpoint where a payload_temp is one of the arguments. It’s obviously a shame that endpoint arguments can’t be directly set as an API schema.

On that second endpoint you can now traverse the body object just as you would have done on the first. You can also delete your payload_temp object once you’re done with it.


Hi @jonah.deleseleuc

I advise you to put only in your first API the “Return” and to call with all the other parameters the second API which will process the information. If Bubble bugs during a search, the delay can easily exceed 10 seconds. The described method allows to have a return in 2 seconds or less even with several calls to API 1 at the same time.


I’d say, like @exception-rambler, you need a faas solution like aws or GCP. Both are solid af and can do the long running task and finish up by sending the data back to bubble.