How to Connect Vapi to n8n: Complete Step-by-Step Guide (2026)

Vapi handles the voice. n8n handles everything else. Together they form the backbone of almost every production voice agent in the wild, because Vapi on its own cannot check a calendar, update a CRM, send a confirmation text, or look up a customer record. It needs a backend that executes business logic, and the way the two systems talk to each other is through webhooks.

The problem is that most tutorials show you a hello-world webhook and then leave you stranded when the real questions come up. How do you pass the caller's phone number to n8n? How do you return a response mid-call that Vapi actually speaks back? What goes in the end-of-call report and how do you log it? This guide walks through every integration point between Vapi and n8n with real payloads you can paste into your own workflow.

The Three Ways Vapi Talks to n8n

Before writing any code, understand the three distinct integration points, because each one behaves differently and sends a different payload shape. First is the server URL webhook, which is a global listener for every Vapi event across every assistant. Second is custom tools, also called function calls, which trigger mid-conversation when the AI decides it needs to do something like check availability or book an appointment. Third is the end-of-call report, which fires once when the call terminates and contains the full transcript, recording URL, structured data summary, and call metadata.

Most production voice agents use all three. The server URL catches events for logging and analytics, custom tools handle real-time lookups during the call, and the end-of-call report drives the CRM sync, SMS confirmation, and Slack alert workflows that run after the caller hangs up.

Step 1: Create the n8n Webhook

Open n8n and start a new workflow. Add a Webhook node as the trigger. Set the HTTP method to POST and leave the path on its default or rename it to something descriptive like vapi-tool-call. Toggle the response mode to "Respond to Webhook" so n8n can send a response back that Vapi will use mid-conversation. Copy the production URL, not the test URL, because Vapi will keep calling the test URL only while your workflow is actively listening for one execution.

This is the single biggest beginner mistake with Vapi and n8n. The test URL expires after every execution, which makes the next call from Vapi silently fail with no error in the n8n UI. Always activate the workflow and use the production URL for any assistant that will run unattended.

Step 2: Configure the Vapi Custom Tool

In the Vapi dashboard, open your assistant and scroll to Tools. Create a new custom tool. Give it a function name like checkAvailability, add a description that tells the LLM when to use it such as "Use this to check appointment availability for a given date", and define parameters using JSON schema. Parameters are what Vapi extracts from the conversation and passes to n8n. A typical availability check tool takes a date parameter of type string with format date, and a serviceType parameter as a string enum of the services offered.

Paste the n8n production webhook URL into the server URL field for the tool. Vapi will POST to this URL every time the LLM decides to invoke the tool mid-call, and it expects a response within about 7.5 seconds or the caller will hear awkward silence.

Step 3: Parse the Incoming Payload

When Vapi fires a tool call to your webhook, it sends a payload with a specific nested structure you have to respect. The payload arrives as a body with message.toolCalls, which is an array because Vapi can request multiple tool calls in parallel. Each tool call has an id, a function object with the name and arguments, and the arguments come in as a stringified JSON object that you need to parse.

In n8n, the easiest way to extract the tool call data is to add a Set node right after the webhook and assign variables. The toolCallId lives at body.message.toolCalls[0].id and the parsed arguments live at body.message.toolCalls[0].function.arguments. You need the toolCallId because your response has to reference it back to Vapi so it knows which tool call you are answering.

Step 4: Build the Business Logic

This is where n8n shines. After parsing the tool call, you can branch into whatever business logic the tool needs. For an availability check, add an HTTP Request node to query your booking platform, Google Calendar, or Cal.com. For a CRM lookup, query HubSpot or Airtable. For a knowledge base question, send the query to a vector database or to a GPT node with the relevant context.

Keep the entire chain under 5 seconds if you can. Vapi times out at roughly 7.5 seconds and you want to leave margin for network latency. If the logic takes longer than that, have n8n respond immediately with a placeholder like "let me check that for you" and then complete the work asynchronously, updating Vapi via a separate call when the result is ready.

Step 5: Return the Correctly Shaped Response

Vapi expects a very specific response shape. The response must be a JSON object with a results array, where each entry has a toolCallId that matches the incoming call and a result field containing what the AI should say or do with the information. A typical response body looks like this conceptually: an object with a results array, and inside the array an object with toolCallId set to the original tool call ID and result set to a string like "Available times are 2pm, 3pm, and 4:30pm on Thursday."

The result field is critical. Vapi feeds this back into the LLM context so the model can phrase the response to the caller naturally. If you return a raw array of timestamps, the AI will read them verbatim and sound like a robot. If you return a clean human-readable sentence, the AI blends it into the conversation smoothly.

Step 6: Handle the End-of-Call Report

Set up a second n8n workflow with its own webhook to receive the end-of-call report. In the Vapi assistant settings, configure the server URL to point to this webhook and select the events you want, which for most agencies is just end-of-call-report. The payload contains the full transcript, a summary generated by the LLM, the structured data you requested via the data schema, the recording URL, the cost breakdown, and call metadata including duration and end reason.

From this single webhook you can drive a dozen downstream actions. Log the call to Airtable or a database, send an SMS confirmation to the caller with the booking details, Slack-notify the business owner with a summary, update the CRM with the new contact, and kick off a follow-up sequence if the call ended without a booking. The end-of-call workflow is where most of the business value of a voice agent actually happens.

Authenticating the Webhook

By default the webhook is open, which means anyone who finds the URL can fire fake tool calls into your workflow. For production, add a secret header in Vapi under the tool's server configuration, then validate it in n8n using an IF node before executing any business logic. If the secret does not match, respond with an error and exit. This prevents a scraper or bad actor from racking up OpenAI costs or corrupting your CRM with fake bookings.

Common Errors and How to Fix Them

If Vapi logs a 404 from the webhook, the workflow is not active or you are using the test URL. Activate it and switch to production. If Vapi shows the tool call succeeded but the caller hears silence, your response is shaped wrong. The top-level key must be results, not result, and each entry must include the exact toolCallId. If the caller hears a weird truncation, the response arrived after the timeout. Profile the n8n execution time and optimize or cache the slow step.

Next Steps

Once the basic integration works, the natural next additions are a custom knowledge base queried via a tool call, a booking tool that writes to Google Calendar or Cal.com, and a transfer tool that dials out to a human when the AI hits its escalation criteria. Each of these is a separate n8n workflow triggered by a separate Vapi tool. Keep the workflows small and single-purpose, because debugging a monolithic workflow that handles five different tool calls is miserable compared to debugging five focused ones.

Most builds spend roughly two days on the Vapi and n8n plumbing and another week on prompt tuning, knowledge base accuracy, and edge case handling. The plumbing is the easy part. Making the agent sound genuinely helpful to a real caller is the hard part, and it has almost nothing to do with the integration itself.