HubSpot workflow webhook failing or not reaching your endpoint: how to find out why

A failing Send a webhook action in a HubSpot workflow usually comes down to what your endpoint sends back. It returns a 4XX error, takes too long to answer, or rejects the request because an API key or signature check fails. HubSpot doesn't retry 4XX responses other than 429, so after one bad response that record's webhook isn't sent again unless you put the record through again.

First, open the workflow's action log for an affected record and read the message next to the webhook action. Then open the action, expand Test action and run a test. The Request and Response tabs show what HubSpot sent and what came back. A test sends real data to the other system, but it doesn't change any records in HubSpot.

Why the webhook action fails

The account doesn't have the action

As of October 2026, HubSpot's list of workflow actions says Send a webhook needs Data Hub Professional or Enterprise, and setting it up needs Edit permission for workflows or super admin. It works in every workflow type, though historical property values are only sent from contact-based workflows.

The endpoint returns a 4XX error

Typical 4XX causes are a wrong URL or path, an authentication header the endpoint doesn't expect, and a body it can't parse. The URL has to start with HTTPS. If you authenticate with an API key, check the key name and whether the key goes in the query parameters or the request header. When the webhook calls HubSpot's own API, HubSpot's webhook setup guide says to pick a secret whose value is Bearer YOUR_TOKEN, use Authorization as the key name and put it in the request header.

Check the body too. Include all properties sends every property of the record, while Customize request body sends only the keys you add, from properties or static values. If your endpoint expects a field you didn't add, it may reject the request.

The endpoint is slow or down

HubSpot gives the endpoint a limited time to answer. If it's too slow, HubSpot logs the action as failed and retries later, even when your server did the work, which is how duplicates appear on the receiving side. Server errors are retried too. Retries run for up to three days, starting one minute after the failure, with gaps that grow to a maximum of eight hours. The action log shows these as information messages saying the webhook will retry soon, listed in HubSpot's common workflow errors.

Your endpoint sends 429 with the wrong Retry-After

HubSpot retries after a 429 and respects a Retry-After header, but it reads the value in milliseconds. A server that sends Retry-After: 60 to mean one minute is asking HubSpot to wait 60 milliseconds. If your endpoint can only take so many calls, turn on rate limiting in the action's Configure rate limit section instead. Paused runs then log a message saying when they'll resume, and the actions after the webhook wait too.

Signature validation fails on your side

If you chose Include request signature in header, the action asks for your HubSpot app ID, and HubSpot sends an X-HubSpot-Signature header with the signature version set to v2. Your server hashes the app's client secret, the HTTP method, the full URI and the request body with SHA-256 and compares the result. HubSpot's request validation guide says the URI must match the original request exactly, including the protocol and the order of query parameters. Hash the body exactly as it arrived. HubSpot's KB says the hash uses the unparsed body, and rebuilding parsed JSON can change spacing or key order, so a proxy that rewrites the URL or code that rebuilds the JSON can break the match.

A later action uses an output that isn't there

After a test you can pick fields from the response to use later in the workflow. Pick only fields that come back in every response. If a later action uses an output missing from the response, that action fails, even though the webhook itself worked. For more than one output, the response has to be a JSON object.

How to fix a failing workflow webhook

1. Read the action log message for one failed record and note whether it's an error or an information message that will retry.
2. Run Test action and compare the Request tab with what your endpoint expects.
3. Check your endpoint's own logs for the same time. If the request never arrived, check the URL and anything that filters traffic in front of the server.
4. Fix the API key or signature check until the test returns a 2XX response.
5. Make the endpoint answer quickly, and do slow work after it has responded.
6. Make the endpoint safe to call twice for the same record, since a timeout can cause a retry of work that already ran.
7. Put the failed records through the action again, because HubSpot won't retry the ones that got a 4XX. Workflow action errors explains how to re-enroll records or use a one-off workflow.

How to stop it happening again

Have the endpoint log every request with the record ID and the status it returned, and alert on 4XX responses, since HubSpot won't retry those. HubSpot also describes a quick test with a dummy URL from webhook.site. If you try it, enroll only a test contact, because a POST sends all of the contact's information, and take the API key or secret off the action first so a real token isn't sent to a third-party site. Webhook calls from workflows don't count toward the HubSpot API rate limit, but if your endpoint calls back into HubSpot, those calls do, so read HubSpot API rate limits if you see 429s there.

If your webhooks feed another system and you need someone to trace a failure from end to end, I can audit and fix your workflows.

Questions

How long does HubSpot retry a failed webhook?

Up to three days, starting one minute after the failure, with the gap between attempts growing to at most eight hours. 4XX responses other than 429 aren't retried.

Do workflow webhooks count toward HubSpot's API limits?

No. HubSpot's usage guidelines say webhook calls made by workflows don't count toward the API rate limit.

Can the webhook action pull data into HubSpot?

Yes. Choose GET as the method, add query parameters from properties or static values, then use the response fields in later actions through the data panel.

Should I use custom code instead?

It needs the same Data Hub plans. A custom code action gives you control over headers, retries and how you handle the response, at the cost of a 20-second time limit and code you have to maintain.