There isn’t a setting for the timeout, so there won’t be a way to increase that limit, and we’ll automatically retry in the case of a timeout (the only case we won’t retry is when we did get a response but with a status code of 400, 401, 403, 404, or 405).
Can you provide more details for why you might be running into that timeout? In general, if your process takes more than a second, we’d recommend accepting the data from the webhook request, and then placing that data into a queue that could be processed asynchronously from the webhooks.
Wait! There's a 1 second timeout? I thought it was 2 seconds.
1 second is pretty low. Honestly, I don't understand half the failures. Does backlog timeout mean that there are too many events and the concurrent limit is too low, or does it mean it hit our API but timed out?
There are way too many restrictions and too little documentation about this. Things need to be a bit looser.
I agree that 1 second timeouts are bad. Even when you offload all the processing to another thread you will still have a timeout if your function (google cloud functions / aws lambda) has a cold start.
It is completly crazy to have a 1 second timeout. yes it is good practice not to do any heavy processing for the duration of request, and do it asyncronously through a queue instead. I am having issues where ocasionally my code would be unloaded from the servers memory if the applciation has not been accessed for a period of time. The laoding process on the first request takes over a second, So for the first request after a period of time I have multiple duplicate hubspot messages arriving (because server caches the requests while it loads the applciation)
Please increase the timeout value, or, even better - make it user configurable.
Hi guys,
I’ve managed to fix this issue by making sure the processing of the webhook was queued and made asynchronously.
I have a highly available simple API endpoint for my integration that does nothing else but queueing the webhooks processing tasks.
From there, my main application is polling the queue and it can take any time to write the data into the database and won’t fail anything on Hubspot side.
Best,
__
Lionel
hi [at] getlionel [dot] com
1 second is poor. We receive WebHook on our script. We check other companies exist in our other CRM. Then we go back to HubSpot via the API to pull all contacts. Then we allow HubSpot to push the code over. One second is absolutely poor. INCREASE ASAP PLEASE!!!
It’s true that 1 sec webhook timeout is too less to determine whether the request was a success or not. In my case I am triggering a AWS lambda function which sends a SMS on dealstage change event. But here instead of sending one SMS per one dealstage change it is sending multiple SMSs because the webhook fails to get response code 200 within it’s 1 sec timeout and retries again and again until it gets success code 200 hence sending the same SMS multiple times.
Either the timeout time should increase or it should be up to the developer to set max number of retries.
PS - I am doing a few API calls with my AWS lambda function which takes some time to complete.
When a contact is created in HubSpot i get a webhook request to a web API with the contact id, then i retrieve that contact from HubSpot API and then i create that record in CRM. Apparently this process takes more than 1 second.
Basically I need to create a record in CRM each time a Contact is created in HubSpot. I would be happy if there is a better solution. Thanks!
There isn’t a setting for the timeout, so there won’t be a way to increase that limit, and we’ll automatically retry in the case of a timeout (the only case we won’t retry is when we did get a response but with a status code of 400, 401, 403, 404, or 405).
Can you provide more details for why you might be running into that timeout? In general, if your process takes more than a second, we’d recommend accepting the data from the webhook request, and then placing that data into a queue that could be processed asynchronously from the webhooks.