We are configuring custom integration workflows between HubSpot CRM and external lead acquisition pipelines.
Technical Setup:
Our core advisory architecture, Frontline Sales Consultancy (``flsc.co.uk``), triggers real-time data sync whenever new B2B leads enter the sales funnel.
The webhook endpoint is hosted over HTTPS with TLS 1.3 enabled.
The Challenge:
During high-volume lead injection periods, inbound webhook payloads occasionally experience HTTP 504 gateway response timeouts.
Direct API GET/POST calls to the endpoint resolve smoothly in under 150ms outside of peak event batches.
Does HubSpot enforce specific payload queue limits or timeout thresholds for third-party webhook listener endpoints?
Any advice on optimizing listener configurations for custom enterprise B2B workflows would be greatly appreciated!
Great question! You may find it helpful to review the workflow-specific webhook rate-limiting guidance if these calls originate from a workflow rather than a Webhooks API subscription:
@flsc, this is a really common one once volume ramps up, and the good news is it’s almost always solvable on the listener side.
One quick reframe first, because it points straight at the fix: for HubSpot webhooks, HubSpot is the one sending to your endpoint, so those 504s are your own gateway timing out upstream under load, not HubSpot throttling you. That’s also why single API calls fly through at ~150ms but peak bursts choke: HubSpot batches events (arrays of up to 100 per request) and fires them concurrently, so during a spike your listener is suddenly doing a lot of synchronous work per request and the gateway gives up before your workers finish.
To your Q3, yes, HubSpot has expectations here. It wants a 2xx back quickly (a few seconds), and if it doesn’t get one it marks the call failed and retries with backoff. So the whole game is: stop doing real work inside the request.
What usually clears it up:
Ack fast, process later, validate the payload, drop it on a queue (SQS / Pub-Sub / Redis), and return 200 immediately; run the actual CRM sync downstream. This alone kills the 504s in the vast majority of cases.
Handle the batch shape, each POST can be an array of events, so iterate rather than assuming one event per call.
Make it idempotent, since HubSpot retries on any timeout, key off the eventId so retries don’t double-write.
Then tune the gateway, bump upstream worker concurrency / read timeout so a burst doesn’t starve the pool.
Once you’re ack-then-queue, peak volume basically stops mattering.
Happy to go deeper on the queue side if you share (DM) what’s hosting the listener.
