How to Send Vapi End of Call Report to n8n

Every Vapi call ends with a complete record: transcript, summary, cost breakdown, timestamps, analysis results, and caller details. In most setups, that record stays inside Vapi. Nothing routes to the CRM. Nothing posts to Slack. The sales team never sees the summary. The QA process never happens.

Connecting Vapi to n8n fixes that. When a call ends, Vapi sends the full report as a webhook to n8n, and n8n routes it wherever your team needs it: a HubSpot note, a Slack alert, a Postgres row, a Zendesk ticket. The setup takes about thirty minutes, and once running, it handles every call automatically without anyone touching it.

This guide covers the production version of the setup, not just the test path. You will learn how to receive the webhook reliably, confirm the payload structure, extract the right fields, avoid duplicates, handle errors, and keep the endpoint secure.

TLDR

To send a Vapi end-of-call report to n8n:

Create a new n8n workflow.
Add a Webhook trigger node.
Set the webhook method to POST.
Copy the n8n Test URL while testing, or the Production URL once live.
Add that URL to your Vapi assistant or server configuration.
Make sure Vapi is configured to send the end-of-call-report server message.
Trigger a test call.
Inspect the incoming JSON payload in n8n.
Extract fields such as call.id, message.analysis.summary, message.artifact.transcript, message.cost, and metadata.
Route the cleaned data to Slack, HubSpot, Salesforce, Airtable, Postgres, Google Sheets, or another destination.

The most important production rule is simple: respond to Vapi quickly with a successful HTTP response, then do heavier processing afterward. This reduces webhook retries, prevents duplicate records, and makes your voice AI automation more reliable.

How do Vapi end of call report webhooks work?

Vapi end-of-call report webhooks work by sending an HTTP POST request to your configured server URL after a call ends. The request contains a JSON payload with the finalized call data.

According to the Vapi webhook documentation, Vapi can send server messages to your endpoint when specific call events occur. For end-of-call processing, the key server message is typically end-of-call-report.

In practice, the flow looks like this:

A Vapi-powered call starts.
The assistant handles the conversation.
The call ends.
Vapi generates the final report.
Vapi sends a webhook request to your server URL.
n8n receives the payload.
Your workflow validates, transforms, and routes the data.

This is an asynchronous integration. n8n does not poll Vapi for call updates. Instead, it waits for Vapi to push the event when the call is complete.

That matters because your n8n webhook must be:

Publicly reachable from the internet
Configured to receive POST requests
Active in production mode when you go live
Fast enough to acknowledge the webhook
Reliable enough to avoid losing important call records

For voice AI operators, this webhook becomes the bridge between conversation and operations. Without it, call summaries and transcripts often stay trapped in the voice platform. With it, every call can become a CRM activity, a QA item, a sales notification, a support ticket, or a structured analytics record.

Why is the Vapi end-of-call report the best event to send to n8n?

The Vapi end-of-call report is usually the best event to send to n8n because it contains the most complete version of the call data.

Real-time events are useful for monitoring active calls, but they may not include final values. During a live call, duration, cost, transcript, summary, and analysis can still change. Once the call ends, the final report is much more useful for downstream automation.

The end-of-call report may include:

Final call status
Call start and end timestamps
Total call duration
Final transcript or transcript artifacts
Assistant and customer details
End reason
Cost and cost breakdown
Recording URL, if enabled and permitted
Summary and structured analysis
Custom metadata attached to the call
Compliance or recording consent information, depending on configuration

This makes it the right event for workflows like:

“Add the call summary to the CRM”
“Notify the sales team when a qualified lead finishes a call”
“Create a support ticket if the caller requested escalation”
“Store transcript and cost data in a reporting database”
“Flag low-quality calls for review”
“Update a lead score based on call analysis”

A helpful way to think about it: real-time call events are for monitoring, while end-of-call reports are for business records.

What do you need before connecting Vapi to n8n?

Before connecting Vapi to n8n, make sure you have access to both platforms and a basic plan for where the call data should go after n8n receives it.

You will need:

A Vapi account with an assistant or call flow configured
Access to the Vapi dashboard or assistant configuration
An n8n instance, either n8n Cloud or self-hosted
Permission to create workflows in n8n
A public webhook URL from n8n
A destination for the processed call data, such as Slack, a CRM, a database, or email

You should also decide what you want to do with the report before building the workflow. Common destinations include:

Destination	Common use case
Slack	Send real-time summaries to sales, support, or operations
HubSpot	Log calls against contacts, companies, or deals
Salesforce	Create tasks, activities, or lead updates
Airtable	Store lightweight call records for review
Postgres	Build a structured call analytics database
Google Sheets	Simple reporting and manual review
Zendesk	Create tickets from support calls
Notion	Maintain a call review workspace

For early testing, Slack or Google Sheets is often easiest. For production, a database or CRM is usually better because it provides stronger structure, deduplication, and reporting.

How to configure a Vapi webhook URL in n8n

To configure a Vapi webhook URL in n8n, create a workflow with a Webhook trigger node, set it to receive POST requests, then copy the webhook URL into Vapi as the server URL.

Here is the recommended setup.

Create the n8n webhook trigger

In n8n:

Open n8n.
Create a new workflow.
Add a Webhook node.
Set HTTP Method to POST.
Choose a clear path, such as vapi-end-of-call-report.
Set the response behavior so the workflow can return a success response.
Save the workflow.

The n8n Webhook node documentation explains the node’s available options, including test URLs, production URLs, response modes, and authentication options.

Your webhook path should be specific enough that it is not easy to guess. Avoid generic paths like webhook or test. A better path might be something like vapi-eoc-voiceops-2026, combined with proper authentication or token checks.

Use the test URL first

n8n provides a Test URL and a Production URL.

Use the Test URL while you are building. In test mode, n8n waits for one incoming request and shows you the payload immediately. This is useful for understanding the exact JSON structure Vapi sends.

Typical testing flow:

Click Listen for test event in n8n.
Copy the n8n Test URL.
Paste it into Vapi as the server URL.
Trigger a Vapi test event or complete a test call.
Confirm that n8n receives the payload.

Once everything works, switch Vapi to the n8n Production URL and activate the workflow.

Move to the production URL when ready

The Production URL only works when the n8n workflow is active. This is the URL you should use for live Vapi calls.

Before going live, confirm:

The workflow is activated.
The Production URL is saved in Vapi.
The workflow returns a success response.
Your downstream nodes are tested.
Errors are routed somewhere visible.
Duplicate webhook handling is in place.

This transition from test URL to production URL is a common source of confusion. If your test works but production does not, check whether the workflow is active and whether Vapi is pointing to the production endpoint.

How to configure Vapi to send the end-of-call report to n8n

To configure Vapi to send the end-of-call report to n8n, add the n8n webhook URL as the Vapi server URL and make sure your assistant is configured to send the end-of-call-report server message.

Depending on how you manage Vapi, you may configure this in the dashboard, through an assistant configuration, or through API settings.

The key items are:

Server URL: the n8n webhook URL
Server messages: include end-of-call-report
Assistant or call configuration: confirm the setting applies to the assistant handling the calls

Vapi support discussions commonly refer to enabling the end-of-call-report event through the serverMessages array. If this server message is not enabled, Vapi may not send the final report even if the URL is correct.

A typical configuration concept looks like this in plain terms:

Server URL: your n8n webhook URL
Server messages: end-of-call-report

After saving the setting, place a test call and wait until it fully ends. The webhook is not sent at call start. It arrives after the call has completed and the report is generated.

What fields are included in a Vapi end of call report?

A Vapi end-of-call report usually includes call identifiers, timestamps, transcript artifacts, analysis, cost data, end reason, and related assistant or customer information. The exact payload can vary based on your Vapi configuration, enabled features, and API version.

You should inspect the real payload in n8n before assuming field paths.

Common fields include:

Field or object	What it usually means	How you might use it
`message.type`	Event type, usually `end-of-call-report`	Validate the webhook before processing
`message.call.id`	Unique call ID	Deduplication and CRM reference
`message.call.status`	Call status	Reporting and filtering
`message.startedAt`	Call start time	Timeline and analytics
`message.endedAt`	Call end time	Timeline and analytics
`message.endedReason`	Why the call ended	QA and troubleshooting
`message.cost`	Total call cost	Cost tracking
`message.costBreakdown`	Detailed cost components	Margin and provider analysis
`message.artifact.transcript`	Transcript text or structured transcript	CRM notes, QA, search
`message.artifact.recordingUrl`	Recording URL, if enabled	Review and compliance
`message.analysis.summary`	AI-generated call summary	CRM summary and Slack alert
`message.analysis.structuredData`	Extracted structured fields	Lead qualification and routing
`message.assistant`	Assistant details	Multi-assistant reporting
`message.customer`	Customer or caller details	CRM matching
`message.call.metadata`	Custom metadata	Routing, attribution, tenant mapping

In n8n, the incoming webhook payload may be wrapped under body, depending on the Webhook node configuration. For example, you may see paths like:

body.message.type
body.message.call.id
body.message.analysis.summary
body.message.artifact.transcript

Do not rely only on examples from tutorials. Always use the first real test payload as the source of truth.

How to parse Vapi webhook payloads in n8n

To parse Vapi webhook payloads in n8n, use the incoming Webhook node output, then add Set, Edit Fields, Code, If, or Item Lists nodes to extract and normalize the fields you need.

A clean n8n parsing flow might look like this:

Webhook node: receives the Vapi payload.
If node: checks that the event is an end-of-call report.
Set node: extracts core fields into simpler names.
Code or Item Lists node: formats transcripts or nested arrays.
CRM or Slack node: sends the cleaned output to the destination.
Database node: stores the raw payload or normalized record.

For example, you might map fields into a simpler internal structure:

Clean field	Possible Vapi source
`call_id`	`body.message.call.id`
`event_type`	`body.message.type`
`summary`	`body.message.analysis.summary`
`transcript`	`body.message.artifact.transcript`
`recording_url`	`body.message.artifact.recordingUrl`
`started_at`	`body.message.startedAt`
`ended_at`	`body.message.endedAt`
`ended_reason`	`body.message.endedReason`
`cost`	`body.message.cost`
`customer_number`	`body.message.customer.number`
`metadata`	`body.message.call.metadata`

This normalization step makes the rest of your workflow much easier to maintain. Instead of having every downstream node reference deeply nested JSON paths, you create one clean object and reuse it.

How to handle nested transcript arrays from Vapi in n8n

To handle nested transcript arrays from Vapi in n8n, first inspect whether the transcript arrives as plain text, an array of turns, or part of an artifact object. Then convert it into the format your destination expects.

Vapi payloads can include conversation artifacts in different shapes depending on the configuration. You may receive:

A plain transcript string
A list of message objects
A structured array with role, text, and timestamp
A recording or artifact URL instead of full inline content

For CRM notes or Slack alerts, a readable transcript format is usually best:

Caller: “I need help rescheduling my appointment.”
Assistant: “Sure, I can help with that. What day works best?”
Caller: “Thursday afternoon.”

For databases, structured JSON may be better because it preserves roles, timestamps, and message order.

In n8n, you can use:

Set node for simple extraction
Item Lists node for splitting arrays
Code node for joining transcript turns into readable text
HTML node or Markdown formatting for CRM notes
Database node for storing the raw transcript object

A good production pattern is to store both:

A human-readable transcript for sales or support teams
The original raw transcript object for future QA and analytics

This helps you avoid losing detail while still making the data easy to use.

How to validate that the webhook is really a Vapi end-of-call report

To validate that the webhook is a Vapi end-of-call report, check the event type before processing the payload. In many Vapi payloads, that means confirming that message.type equals end-of-call-report.

In n8n, add an If node immediately after the Webhook node.

The condition should check something like:

Field: body.message.type
Operator: equals
Value: end-of-call-report

If the condition passes, continue processing. If it fails, return a success response or route it to a debug log, depending on your design.

You should also validate required fields before sending data to a CRM or database. At minimum, check for:

Call ID
Event type
Timestamp
Summary or transcript
Customer identifier, if required for CRM matching

This prevents common workflow failures, such as trying to create a CRM note without a contact ID or trying to store a null transcript in a required database column.

For production workflows, consider three validation layers:

Validation layer	Purpose
Event validation	Confirm this is an end-of-call report
Required field validation	Confirm important fields exist
Destination validation	Confirm the CRM, Slack, or database payload is valid

Voice AI operations often involve multiple providers, destinations, and teams. At Voxfra, we generally recommend treating the end-of-call report as an operational record, not just a notification. That means preserving the raw payload, validating the normalized fields, and keeping routing logic separate from provider-specific payload quirks.

How to respond to the Vapi webhook in n8n

To respond to the Vapi webhook in n8n, return a fast 200 OK response after receiving the request. This tells Vapi that your endpoint accepted the webhook.

n8n gives you a few ways to respond:

Use the Webhook node’s built-in response settings.
Use a Respond to Webhook node.
Respond immediately, then continue processing in another workflow.

The n8n Respond to Webhook documentation explains how to control the response body, response code, and timing.

For production, the safest pattern is:

Receive the webhook.
Validate it lightly.
Store the raw event or enqueue it.
Respond 200 OK.
Process the call report asynchronously.

This avoids a common problem: the webhook sender waits while your workflow calls multiple external systems. If your CRM is slow or Slack has a temporary issue, the Vapi webhook may time out or retry. That can create duplicates.

The better design is to acknowledge receipt quickly, then handle downstream work separately.

How to route Vapi call summaries to Slack from n8n

To route Vapi call summaries to Slack from n8n, add a Slack node after parsing the Vapi payload and format the summary into a readable team alert.

A useful Slack message might include:

Call outcome
Caller name or number, if available and appropriate
Summary
Duration
End reason
Qualification result
CRM link
Recording link, if enabled and compliant
Internal owner or team

Example Slack alert structure:

New Vapi call completed
Outcome: Qualified lead
Summary: Caller asked about pricing and requested a follow-up tomorrow.
Duration: 4 minutes 32 seconds
End reason: Customer ended call
Next step: Create sales task
Call ID: call_abc123

Keep Slack messages short. The goal is not to dump the full JSON payload into a channel. The goal is to help a person decide what to do next.

For longer transcripts, include a link to the CRM record, database entry, or internal call review page instead of posting the entire transcript.

How to route Vapi end-of-call reports to a CRM from n8n

To route Vapi end-of-call reports to a CRM from n8n, match the caller to a CRM contact or lead, then create a note, task, activity, or timeline event using the summary and transcript.

A typical CRM workflow looks like this:

Receive the Vapi end-of-call report.
Extract caller phone number or customer ID.
Search CRM for a matching contact.
If found, create a call note.
If not found, create a lead or route to manual review.
Attach summary, transcript, call ID, timestamp, and recording URL.
Create a follow-up task if the analysis indicates one is needed.

For HubSpot, this may involve contact lookup and note creation. For Salesforce, it may involve lead or contact lookup and task creation. For Zendesk, it may involve creating a ticket with the transcript and call reason.

Good CRM mapping is less about sending every field and more about sending the right fields.

Recommended CRM fields:

CRM field	Source from Vapi report
Call ID	Vapi call ID
Call time	Start and end timestamps
Caller	Customer phone or metadata
Summary	Analysis summary
Transcript	Artifact transcript
Outcome	Structured analysis or custom logic
Follow-up required	Analysis result or keyword logic
Recording	Recording URL, if enabled
Source	`Vapi` or assistant name

If your team operates multiple voice providers, avoid hardcoding every CRM field directly to Vapi-specific paths. A provider-neutral reporting layer can make future migration easier. Voxfra is designed for this kind of operating layer around voice providers, handling call capture, routing, separation, handoff, reporting, and provider portability without replacing your voice agent builder.

How to secure Vapi webhooks sent to n8n

To secure Vapi webhooks sent to n8n, use authentication, secret tokens, strict validation, and limited exposure of your webhook endpoint.

At minimum, you should not leave a sensitive production webhook fully open without any verification.

Common security options include:

Add a secret token in the webhook URL query string.
Use n8n webhook authentication if available for your setup.
Validate a shared secret header if your webhook sender supports it.
Restrict access at the proxy or firewall layer if self-hosting.
Use a long, unguessable webhook path.
Reject requests that do not match the expected event type.
Avoid exposing credentials or private data in Slack messages.
Store recordings and transcripts according to your privacy obligations.

A simple token-based approach looks like this:

Vapi sends to https://your-n8n-domain/webhook/vapi-eoc?token=your-secret
n8n checks whether the token matches
If it matches, continue
If not, stop processing

This is not the same as cryptographic signature verification, but it is better than an unprotected URL. For stronger security, use signed requests if supported by your configuration, or place n8n behind an API gateway that can validate headers and secrets.

Also consider data privacy. End-of-call reports may contain personal data, health details, financial information, or other sensitive content depending on your use case. Only route the fields each destination actually needs.

How to prevent duplicate Vapi call records in n8n

To prevent duplicate Vapi call records in n8n, use the Vapi call ID as an idempotency key before creating records in downstream systems.

Webhook retries are normal in distributed systems. If Vapi does not receive a successful response, or if a network issue occurs, it may send the same event again. Your workflow should assume duplicates can happen.

The simplest deduplication strategy:

Extract call.id.
Check your database, sheet, CRM, or cache for that call ID.
If the call ID already exists, stop processing.
If it does not exist, continue and store the call ID.

Good places to store processed call IDs include:

Postgres
Redis
Airtable
Google Sheets for simple testing
CRM custom field
n8n data store, depending on your setup

For production, a database is usually the strongest option. It gives you a reliable record of processed webhook events and makes it easier to audit failures later.

How to handle errors and retries in n8n

To handle errors and retries in n8n, add a dedicated error workflow, store raw payloads, and make failed downstream operations visible to your team.

n8n supports error handling patterns through workflow settings and Error Trigger workflows. Use them to avoid silent failures.

Recommended error handling pattern:

Store the raw Vapi payload before sending it anywhere else.
Create a normalized call record with status received.
Send data to Slack, CRM, or database.
Update the call record to processed when complete.
If a downstream step fails, update status to failed.
Notify an internal Slack channel or email inbox.
Include the call ID and error message in the alert.

This gives you operational visibility. Instead of wondering whether a call disappeared, you can see whether it was received, processed, failed, retried, or skipped as a duplicate.

Useful status values:

Status	Meaning
`received`	Webhook arrived successfully
`validated`	Required fields passed validation
`processed`	Downstream routing completed
`duplicate`	Event was already processed
`failed`	One or more destinations failed
`ignored`	Event was not an end-of-call report

This pattern is especially helpful as call volume grows. Manual debugging is fine for a few test calls, but not for a production voice AI operation.

How to test a Vapi call report webhook in n8n

To test a Vapi call report webhook in n8n, put the n8n Webhook node into test listening mode, trigger a Vapi test event or complete a real test call, then inspect the received payload.

Use this checklist:

Open your n8n workflow.
Click the Webhook node.
Copy the Test URL.
Click Listen for test event.
Add the Test URL as the Vapi server URL.
Confirm end-of-call-report is enabled.
Place a test call.
End the call.
Wait for Vapi to generate the report.
Confirm that n8n receives the payload.

If nothing arrives, check these items:

Did you use the n8n Test URL while the node was listening?
Did the call fully end?
Is the Vapi server URL saved in the right assistant?
Is end-of-call-report included in server messages?
Is your n8n instance publicly reachable?
Is your self-hosted n8n behind a firewall or invalid SSL certificate?
Did you accidentally use the Production URL before activating the workflow?

Testing should include more than one call. Try short calls, long calls, calls with no answer, calls with transfers, and calls where the user hangs up. Different endings can produce different values in the report.

What is the best production architecture for Vapi to n8n?

The best production architecture for Vapi to n8n separates webhook intake from heavier processing. This keeps the webhook fast and makes downstream failures easier to recover from.

A strong production design looks like this:

Intake workflow
- Receives the Vapi webhook
- Validates event type
- Stores raw payload
- Creates an idempotency record
- Responds quickly with 200 OK
Processing workflow
- Loads the stored payload
- Normalizes fields
- Formats summary and transcript
- Routes to CRM, Slack, database, or ticketing system
- Updates processing status
Error workflow
- Captures failed executions
- Sends internal alerts
- Provides retry instructions or links

This design is more reliable than placing every action behind one webhook response. It also makes it easier to change destinations later without touching the Vapi webhook configuration.

For example, if you later add Salesforce after starting with Slack, you can update the processing workflow without changing the intake URL.

What metrics should I track after sending Vapi reports to n8n?

After sending Vapi reports to n8n, track metrics that measure reliability, cost, call quality, and business outcomes.

Useful operational metrics include:

Webhooks received
Webhooks processed successfully
Webhook processing failure rate
Duplicate webhook count
Average processing time
Calls missing summaries
Calls missing transcripts
CRM sync success rate
Slack notification success rate

Useful voice AI metrics include:

Call duration
End reason distribution
Cost per call
Cost per qualified lead
Transfer rate
Escalation rate
No-answer rate
Containment rate
Follow-up required rate
Sentiment or outcome labels, if available

Industry research consistently shows that automation reliability depends on observability, not just workflow creation. For example, Gartner has reported ongoing enterprise investment in automation and AI-enabled workflows, while McKinsey has highlighted that generative AI value depends heavily on redesigning workflows around measurable business outcomes rather than simply adding AI tools. The same principle applies here: the webhook is valuable because it turns conversations into measurable operational data.

Start simple. Track whether every completed call creates one clean record in your system of record. Once that is reliable, add richer metrics.

Common mistakes when sending Vapi end-of-call reports to n8n

The most common mistakes are usually configuration and reliability issues, not complex technical problems.

Watch out for these:

Using the n8n Test URL in production
Forgetting to activate the n8n workflow
Not enabling end-of-call-report in Vapi server messages
Expecting the report before the call fully ends
Sending raw JSON directly to Slack
Not validating the event type
Not checking for duplicate call IDs
Creating CRM records without matching contacts first
Letting CRM failures break the webhook response
Ignoring privacy and recording consent requirements
Not storing the raw payload for debugging
Hardcoding field paths without testing real payloads

The most reliable teams treat webhook integrations like small production systems. They validate inputs, store raw events, track status, and design for retries.

FAQs

What fields are included in a Vapi end of call report?

A Vapi end-of-call report commonly includes the event type, call ID, status, start time, end time, end reason, cost, transcript artifacts, recording URL, summary, structured analysis, assistant details, customer details, and metadata. The exact fields depend on your Vapi configuration, so always inspect a real payload in n8n before finalizing mappings.

How to test a Vapi call report webhook in n8n

Use the n8n Webhook node’s Test URL and click Listen for test event. Add that Test URL as the Vapi server URL, confirm that end-of-call-report is enabled, then complete a test call. When the call ends, n8n should receive the JSON payload.

Can I route Vapi data to multiple destinations simultaneously?

Yes. In n8n, you can branch the workflow after parsing the payload. For example, one branch can send a Slack alert, another can create a CRM note, and another can store the raw report in a database. For production, consider storing the payload first, then processing each destination independently.

What happens if my n8n server is temporarily down?

If your n8n server is down, Vapi may not be able to deliver the webhook successfully. Webhook senders often retry failed requests, but you should not depend only on retries. Use idempotency checks based on call.id so duplicate deliveries do not create duplicate CRM notes or alerts.

Is it necessary to secure my Vapi webhook?

Yes. A webhook URL can accept inbound requests from the internet, so you should protect it. Use a secret token, authentication, header validation, an API gateway, or another verification method. You should also validate the event type and avoid routing sensitive transcript data to unnecessary destinations.

Should I store the raw Vapi payload or only the parsed fields?

Store both if possible. Parsed fields are easier for reporting and CRM workflows, while the raw payload is useful for debugging, audits, and future changes. If Vapi adds fields or your team needs a new data point later, the raw payload gives you more flexibility.

Can Voxfra replace this n8n workflow?

Voxfra is not a voice agent builder and does not replace n8n as a general automation tool. It operates around voice providers, helping with call capture, routing, separation, handoff, reporting, and provider portability. Teams that use n8n for workflow automation can still use a provider-neutral operating layer when they need more control across multiple voice systems.

Conclusion

Sending Vapi end-of-call reports to n8n is one of the fastest ways to make a voice AI system operationally useful. Instead of leaving transcripts, summaries, and call outcomes inside the voice platform, you can move them into the systems where your team already works.

The basic setup is straightforward: create an n8n Webhook trigger, configure Vapi to send the end-of-call-report event, test the payload, and map the fields. The production setup requires a little more care: validate the event type, secure the endpoint, respond quickly, store raw payloads, prevent duplicates, and route errors to a visible place.

If you build the workflow this way, you get more than a webhook connection. You get a reliable post-call automation layer that can support sales, support, QA, compliance, reporting, and cost tracking.

For teams building more complex voice AI operations across providers, Voxfra can sit around the voice stack as an operating layer for call capture, routing, handoff, reporting, and provider portability. But even if your stack is only Vapi and n8n today, the same principle applies: capture the call event cleanly, preserve the record, and route the right information to the right system.

Next step

Start with one simple workflow: receive the Vapi end-of-call report in n8n, validate end-of-call-report, extract the call ID and summary, then send a formatted Slack message.

Once that works reliably, add CRM logging, transcript storage, deduplication, and error handling. That phased approach will get you from a basic webhook test to a production-ready voice AI operations workflow without overcomplicating the first build.