Vapi Webhook Not Firing? 11 Reasons It Fails and How to Fix Each One

You configured the Vapi server URL, pointed it at your webhook endpoint, placed a test call, and nothing happened on the other side. No request, no log, no error. This is the single most common issue people hit with Vapi, and the frustrating part is that Vapi itself almost never tells you why. Below is a ranked checklist of the eleven reasons a Vapi webhook fails silently, starting with the ones responsible for roughly 80 percent of cases.

1. You Are Using the Test URL Instead of the Production URL

This is the number one cause. If you are using n8n, Make.com, or Zapier, every webhook has a test URL and a production URL. The test URL only listens while you are actively watching the trigger in the editor, and it expires after receiving one request. The production URL listens persistently once the workflow is activated. Vapi fires tool calls and end-of-call reports asynchronously, often several minutes after you last looked at the editor, so the test URL is almost always expired by the time Vapi tries to reach it.

Fix: activate the workflow and copy the production URL. In n8n this is the URL without the /webhook-test/ segment, just /webhook/.

2. The Workflow Is Inactive

Even with the production URL, n8n returns a 404 if the workflow is not toggled active. The Vapi call logs show the webhook failing but Vapi does not retry and does not surface the error to the caller. Open the workflow, toggle the Active switch at the top right, and retry.

3. The Payload Shape Does Not Match What Vapi Expects

For tool calls, Vapi expects a response body with a specific shape. The top-level key must be results as an array, each entry must include toolCallId matching the incoming call, and each entry must include a result field as a string. If you return the result object without the results wrapper, Vapi accepts the 200 status but speaks nothing back to the caller, making it look like the webhook failed when it actually succeeded but returned a malformed response.

4. The Response Took Longer Than 7.5 Seconds

Vapi has a hard timeout of roughly 7.5 seconds on tool call responses. If your workflow takes longer than that, Vapi cancels the request and the caller hears awkward silence. Look at your n8n execution time for the workflow. If any single step takes over 3 seconds, that is probably your bottleneck. The usual culprits are slow CRM APIs like HubSpot or GoHighLevel, uncached database queries, and GPT-4 calls with long prompts.

5. The Server URL Is Set on the Wrong Object

Vapi has server URLs at multiple levels. There is an org-wide server URL in your account settings, a server URL on each assistant, and a server URL on each individual tool. Events route to the most specific URL. If you set the URL on the org but the assistant has its own server URL configured, the assistant-level URL wins. If you set it on the tool but the assistant also has one, the tool-level URL wins only for that tool's function call events, not for end-of-call-report events.

Open Dev Tools in the Vapi dashboard, inspect the assistant config, and check which serverUrl is actually set at each layer. Remove the ones you do not want.

6. You Are Subscribed to the Wrong Events

In the server URL settings you choose which events fire. The default is typically only end-of-call-report. If you are expecting tool calls to hit your webhook but only selected end-of-call-report, tool calls go nowhere. Check the serverUrlSecret and serverUrl event list and make sure function-call or tool-calls is included depending on your tool configuration.

7. The Tool Is Configured but Never Triggered by the LLM

If Vapi never fires the tool call to begin with, it is not a webhook problem. It is a prompt problem. The LLM decides when to invoke a tool based on the tool description and the system prompt. If the description is vague or the system prompt does not mention the capability, the model may hallucinate answers instead of calling the tool. Tighten the tool description to something like "Use this whenever the caller asks about pricing, hours, or location" and explicitly reference the tool in the system prompt.

8. The Secret Header Does Not Match

If you configured a serverUrlSecret or a custom auth header and your webhook validates it, a mismatch causes a 401 or 403. In n8n the webhook hits your IF node, fails the comparison, and exits before running any business logic. Check the exact header name, including the casing, and the exact secret value. Whitespace at the end of a copied secret is the usual culprit.

9. Ngrok or Your Tunnel Expired

If you are developing locally and tunneling through ngrok or Cloudflared, the tunnel URL changes every time the tunnel restarts on a free plan. Vapi still has the old URL saved and silently fails when it tries to reach a dead subdomain. Upgrade to a paid tunnel for a static domain, or update the Vapi server URL every time the tunnel rotates.

10. Vapi Is in Degraded Status

Rare but real. Check status.vapi.ai before assuming your setup is wrong. Vapi has had multi-hour incidents where webhooks fire with long delays or drop entirely. If the status page shows an incident, there is nothing on your side to fix.

11. Your Webhook Endpoint Is Rejecting the Content-Type

Vapi sends application/json. If your endpoint only accepts form-urlencoded, or if a middleware is stripping the content before n8n sees it, the payload arrives empty. This shows up in n8n as a webhook execution with no body data. Check the raw request in your n8n executions tab. If the body is empty but the execution ran, the content type or a preflight issue is the cause.

How to Debug It Fast

Step one: open webhook.site or requestbin and point Vapi's server URL there temporarily. Place a test call. If the request arrives, the issue is somewhere in your n8n workflow. If it does not arrive, the issue is in Vapi's configuration. This two-minute test isolates the problem to one side or the other and saves an hour of guesswork.

After You Fix It: Add Logging

Once the webhook is firing, add a logging step to every n8n workflow so the next time something breaks you have a record to look at. The cheapest option is an Airtable base with columns for timestamp, call ID, tool name, payload, response, and duration. Every Vapi event writes one row. When a caller complains about a failed call, you pull the exact timeline and see where it went wrong rather than trying to reproduce the issue.