Why has my Zoho CRM webhook stopped firing?
Webhooks in Zoho CRM fail silently. There’s no banner, no dashboard alert and usually no email anyone reads. The first sign is normally a downstream symptom: the warehouse system stops receiving orders or the Slack channel goes quiet, sometimes weeks after the actual break.
Work through these in order. Most webhook failures are found at step one or two.
- Open the failure log. Setup > Automation > Actions > Webhooks, click the webhook and read the failure entries. Failures logged means the webhook is firing and your endpoint is rejecting it.
- Confirm the workflow rule fired at all. A webhook is an action attached to a rule. No rule trigger, no webhook.
- Test the endpoint yourself. A curl request from your own machine settles in ten seconds whether the receiving end is alive.
- Check the auth token at the receiving end. Expired credentials are the most common reason a webhook that has worked for months suddenly stops.
- Ask what changed recently. Deleted CRM fields, API updates at the receiver, firewall changes by your hosting provider.
The sections below take each in turn, plus the one fact that matters most: Zoho CRM never retries a failed webhook call.
Where is the webhook failure log in Zoho CRM?
Setup > Automation > Actions > Webhooks. Open the webhook by name and look at its failure log.
Zoho’s placement here is genuinely unhelpful. You attach a webhook to a workflow rule, so the rule is where everyone looks first, but the diagnostics live under Actions, three menus away. Once you find it, the log earns its keep: each failed call is recorded with the HTTP status code your endpoint returned and that code is the best evidence you’ll get. A 401 points at authentication. A 400 points at the payload. A 403 suggests a firewall and a timeout means a server that is down or too slow.
While you’re on this screen, check one more thing: whether the webhook is still active and still associated with its rule. Zoho deactivates webhooks that fail repeatedly and gives you little indication it has done so.
1. The workflow rule behind the webhook never fired
A webhook in Zoho CRM fires exactly when its workflow rule fires. If the rule’s criteria don’t match the record, the webhook does nothing and logs nothing.
The fast test: add a second, harmless action to the same rule, such as a task, then save a record that should qualify. If the task never appears, the rule is where to look. Rule problems have their own list of suspects: execution events set to Create when records arrive as edits, criteria failing on blank fields, deactivated rules and several more. We cover all nine in our guide to workflows not triggering.
2. Your endpoint failed until Zoho disabled the webhook
Zoho calls your URL and expects a 2xx response, quickly. Anything else counts as a failure: a 500 from a crashed application, a 404 from a moved route or a response that takes too long to arrive. Timeouts are the sneaky one. An endpoint that does heavy work before responding can drift past the limit under load while passing every manual test.
After repeated failures, Zoho disables the webhook. This is what turns a brief outage into a permanent one. Your server was down for an hour on Saturday, the webhook racked up failures and now it stays off even though the server has been healthy for days. Fixing the endpoint isn’t enough; you must also re-enable the webhook in CRM.
Test from your own machine before assuming anything:
curl -i -X POST "https://yourapp.example.com/hooks/zoho" \
-H "Content-Type: application/json" \
-d '{"test": true}'If that hangs, errors or returns anything outside the 200 range, the problem is at your end.
3. An auth token expired at the receiving end
Most webhook URLs carry authentication: a token in a query string parameter or an API key in a custom header. Those credentials belong to the receiving system and they expire on its schedule, not yours.
This is the classic cause of a webhook that ran flawlessly for eighteen months and then stopped. Someone rotated keys during a security review. A SaaS platform expired its old tokens. The endpoint starts returning 401, Zoho logs failures and eventually disables the webhook, while the CRM configuration sits there looking exactly as it always has. Nobody thinks to check CRM because nobody changed CRM.
The fix is mechanical: generate a fresh credential at the receiving end, update the URL or header in Setup > Automation > Actions > Webhooks, re-enable the webhook and push a test record through.
4. The payload format changed
Payload problems come from either direction.
From the CRM side, the webhook body is built from field merge parameters. Delete or restructure a custom field the body references and the payload changes shape without anyone touching the webhook configuration. A strict receiver rejects the malformed body with a 400.
From the receiving side, APIs move on. A platform retires an old endpoint version, renames a required key or starts demanding JSON where it previously accepted form-encoded parameters. Zoho keeps sending exactly what it always sent, which is now wrong.
Compare the two ends. The webhook configuration screen shows what Zoho sends, including the body type, which matters more than people expect: Zoho can send form-encoded parameters or a raw JSON body and most receivers accept only one. The receiving platform’s current API documentation tells you what it wants today.
5. A firewall or allowlist is blocking Zoho’s servers
If Zoho’s failure log shows timeouts or 403s while your application logs show nothing arriving at all, the block sits in front of your application: a web application firewall, an IP allowlist, bot protection on a CDN or a corporate proxy.
This one tends to follow an infrastructure change. A server migration, a tightened WAF rule, an IT policy that allowlists known IP addresses and never included Zoho’s. Older servers also get caught on TLS: an endpoint that only speaks an outdated TLS version will have the handshake refused before your code ever runs.
Ask whoever runs the receiving infrastructure what changed around the date the failures started. The failure log gives you that date.
Does Zoho CRM retry failed webhooks?
No. One attempt per event, then nothing. If your endpoint was mid-deploy for ninety seconds, every record saved in those ninety seconds is missing from the downstream system and Zoho won’t send them again. There is no replay button.
That single fact should shape how you build anything important on webhooks. Three patterns we use on client systems:
- Log before you process. The endpoint’s first job is writing the raw payload somewhere durable. Validation and business logic come after. When something breaks downstream, you can replay from your own log.
- Reconcile on a schedule. A daily job comparing records modified in CRM against calls received at the endpoint catches gaps within a day instead of within a quarter. Even a crude count comparison is worth having.
- Queue anything critical. The endpoint validates the call, drops it on a queue and returns 200 in milliseconds. A worker processes the queue with retries and backoff. This keeps responses well inside Zoho’s timeout and isolates downstream failures from the webhook itself. If the worker writes back into Zoho, watch your API limits; a worker chewing through a backlog can burn the daily allowance fast.
A lighter option for plain visibility: replace the webhook action with a Deluge custom function. invokeurl lets you read the response and shout when it fails, which a native webhook never will:
payload = Map();
payload.put("dealId", dealId.toString());
resp = invokeurl
[
url :"https://yourapp.example.com/hooks/zoho"
type :POST
parameters:payload.toString()
detailed:true
];
if(resp.get("responseCode") != 200)
{
sendmail
[
from :zoho.adminuserid
to :"ops@yourcompany.co.uk"
subject :"CRM webhook call failed"
message :"Endpoint returned " + resp.get("responseCode") + " for deal " + dealId
];
}If the receiving end is Zapier rather than your own server, the diagnosis is similar but with some Zapier-specific wrinkles - our Zoho Flow vs Zapier guide covers where the two differ.
Quick diagnostic checklist
- Open Setup > Automation > Actions > Webhooks and read the failure log. Note the status codes and the date failures began.
- Is the webhook still active and still attached to its rule? Zoho disables webhooks after repeated failures.
- Did the workflow rule fire at all? Add a temporary task action to the same rule and test.
- curl the endpoint from your own machine. Anything other than a 2xx is your answer.
- Check the auth token at the receiving end. A 401 or 403 in the log points here.
- Compare the payload against what the receiver currently expects, including form-encoded versus JSON.
- Ask hosting or IT what changed on the failure start date: WAF rules, allowlists, TLS, migrations.
- Fixed it? Re-enable the webhook in CRM. Fixing the endpoint alone does nothing.
When to stop debugging and get help
Most of the causes above are findable in under an hour. The ones that aren’t tend to involve several systems failing politely at once: a webhook feeding middleware feeding an ERP, where every layer insists it’s fine. This is the point where most people should stop and get help, because the cost of a missing-orders gap grows by the day.
If records are failing to reach a system you bill from or ship from, our emergency Zoho developer service puts a senior developer on the problem within 30 minutes during UK business hours. For the longer-term fix, meaning webhooks replaced with monitored, queue-backed integrations that tell you when something breaks, that’s the core of our Zoho integrations work.
H4Z is a UK-based team working with clients worldwide. The discovery consultation is free and our pricing is published, so get in touch and we’ll tell you whether you’re looking at an hour’s fix or an architecture problem.