Blog · August 4, 2026 · 9 min read

How to Connect Retell AI to n8n: The Automation Layer That Turns Calls Into Booked Jobs (2026)

By Nabeel Hassan — builder of VoiceDash

How to Connect Retell AI to n8n: The Automation Layer That Turns Calls Into Booked Jobs (2026)

TL;DR: Retell handles the conversation. n8n handles everything that has to happen because of the conversation. You connect them in two places: mid-call custom functions, where the agent calls an n8n webhook to check a calendar or look up a customer and gets an answer back inside the call, and post-call webhooks, where Retell posts the finished call to n8n so you can create the CRM record, send the text, notify the owner, and log the outcome. I build production voice agents for US clients on Retell, n8n, GoHighLevel, and Twilio, and I run VoiceDash, the white-label client portal agencies use to show clients what those agents actually did. Here is how I wire the two together.

Most agency owners get their first Retell agent sounding great and then hit the same wall. The agent answers, qualifies, and says it booked the appointment, but nothing moved in the client's CRM, nobody got a text, and the owner has no idea a call happened. The agent is the front door. n8n is the plumbing behind it, and until you build that plumbing you are selling a very convincing voicemail.

Why n8n instead of hardcoding it

You can call APIs directly from a small server, and for a single agent that is fine. The reason I use n8n across every client build is boring and practical:

  • Every client wants a different destination. One books into GoHighLevel, one into Google Calendar, one into a scheduling tool nobody has heard of. The agent prompt should not change because the calendar changed.
  • You can see what broke. n8n stores every execution with the full payload. When a client says "the agent said it booked me and it did not," you open the execution and know within a minute whether Retell sent bad data or the calendar API rejected it.
  • It is one place to add retries. Calendar APIs fail. n8n retries. Your agent does not need to know, and if you hire, a VA can duplicate a workflow for a new client without touching code.

If you have not assembled the rest of the stack yet, how to start a voice AI agency covers the Retell, Twilio, and n8n pieces end to end.

The two integration points, and why the difference matters

This is the part people get wrong, so be clear about it before you build anything.

1. Mid-call custom functions (the agent is waiting)

Retell lets you define a custom function or tool on the agent that points at an HTTP endpoint. When the agent decides it needs information, it calls your endpoint, waits for the response, and then speaks the answer. This is how you get "I have Thursday at 2 or Friday at 10, which works?" instead of an agent that invents availability.

The critical constraint: the caller is sitting there in silence while your workflow runs. Everything on this path is a latency budget. Keep the workflow to the fewest possible nodes, hit exactly one API, and return a small JSON object. If a mid-call workflow takes four seconds, the caller thinks the line dropped.

Use mid-call functions only for things the agent genuinely cannot continue without:

  • Real calendar availability
  • Is this address inside the service area
  • Is this an existing customer, and what is their last appointment
  • Reserving the slot the caller just accepted

2. Post-call webhooks (nobody is waiting)

Retell also posts call events to a webhook URL you configure: the call started, the call ended, and the call has been analyzed with the transcript and any structured data you asked the agent to collect. Nothing here is time-sensitive, so this is where the bulk of your automation belongs.

Everything that does not have to happen during the call should happen here. Creating the CRM contact, sending the confirmation text, alerting the owner about a hot lead, appending a row to a reporting sheet, tagging the lead source. If you find yourself trying to do all of that in a mid-call function, stop and move it.

Wiring it up, step by step

Step 1: Create the webhook in n8n first

Add a Webhook node in a new n8n workflow, set it to POST, and copy the production URL. Turn the workflow on and fire a test request at it. If you are self-hosting n8n behind a home network, this is the moment you find out your URL is not reachable from the internet. Fix that now, not while debugging a live call.

Step 2: Point Retell at it and capture a real payload

In the Retell dashboard, set the agent's webhook URL to your n8n URL, then place one test call and let it complete. Open the execution in n8n and read the payload it received. Field names and event shapes change as Retell ships updates, so build your workflow against the payload you actually received rather than what a blog post said the payload looks like, including this one. Check the current Retell docs for the authoritative field list.

Branch immediately on the event type. A Switch node right after the webhook, splitting call started, call ended, and call analyzed, keeps one workflow from doing three unrelated jobs badly.

Step 3: Verify the request is really from Retell

Your webhook URL is a public endpoint that creates CRM records. Retell signs its webhook requests, so verify the signature in the workflow and drop anything that fails. At minimum, keep the URL unguessable and check a shared secret header before any node that writes data. This takes ten minutes and it is the difference between an integration and a liability.

Step 4: Build the post-call workflow

The sequence I use on almost every client build, in order:

  1. Verify the signature, then filter to the analyzed event so you have the transcript and structured fields.
  2. Normalize the data with a Set node. Pull out caller number, name, intent, whether an appointment was booked, the requested time, and the call outcome. Everything downstream reads these clean fields instead of digging into the raw payload.
  3. Route by outcome. Booked, needs a callback, spam, wrong number, or emergency. Each goes somewhere different.
  4. Write to the CRM. Create or update the contact, attach the transcript, tag the source. For GoHighLevel specifically, the field mapping and calendar wiring are in how to add voice AI to your GoHighLevel agency.
  5. Notify a human when it matters. A text or Slack message to the owner for emergencies and high-value leads. Not for every call, or they will mute it in a week.
  6. Log the row for reporting, then finish.

Step 5: Build the mid-call function, carefully

Separate workflow, separate webhook, different rules. One job, one API call, small response.

Take availability as the example. The agent sends the requested day. Your workflow queries the calendar, returns two or three real slots as plain strings, and stops. Do not create the contact here. Do not send a text here. Do not run a second lookup "while we are in there." Every node you add is silence on the caller's end.

Then handle the confirmation as its own function: the agent sends the slot the caller accepted, you write the booking, and you return a simple confirmed or not-confirmed flag so the agent can say the right thing. Have it return something graceful on failure, so the agent says a human will confirm shortly instead of stalling. How you phrase that fallback in the prompt matters more than the workflow does, and the voice AI receptionist prompt guide covers the wording I use.

Four workflows worth building first

These cover most of what clients actually ask for.

Booked appointment to CRM and confirmation text. The default. Post-call, create the contact, attach the transcript, fire the confirmation SMS through Twilio.

Emergency escalation. If the structured data flags an emergency, ring the on-call phone immediately and text the details. For home services this is the feature that sells the retainer, as covered in voice AI for home services.

Missed-detail follow-up. Caller hung up before booking. Wait fifteen minutes, then send a text with a booking link. Recovers real revenue with no extra calls.

Reminder and reschedule calls. Read tomorrow's appointments each afternoon and trigger outbound Retell calls to confirm. Careful with consent and timing rules; the guardrails are in AI appointment reminder calls.

Mistakes that cost me time

Putting slow work in a mid-call function. The number one cause of agents that feel broken. If a caller has to wait, the workflow needs to be one API call.

No idempotency. Webhooks get retried. If your workflow blindly creates a contact each time, one call becomes three records. Check for an existing record by call ID or phone number before you insert.

Trusting the transcript instead of structured fields. Ask the agent to return structured data and read those fields. Parsing a transcript with string matching in a Function node breaks the first time somebody phrases it differently.

No error branch. Every workflow that writes data needs a failure path that alerts you. Silent failures are how you find out at the end of the month that forty bookings never landed.

Building a new workflow per client from scratch. Build one template, parameterize the client-specific values, and duplicate. This is the difference between five clients and twenty five, which is the whole subject of how to scale a voice AI agency.

The part n8n does not solve

Here is the gap I hit on every build. The automations work, the CRM fills up, the texts go out, and the client still asks what they are paying for.

n8n is invisible to your client, and it should stay that way. They should never see your executions, your Retell dashboard, or your API keys. But they do need to see their calls, their bookings, the recordings and transcripts they can spot-check, and how many of those calls came in after hours. Forwarding raw vendor dashboards exposes your stack and teaches the client they could go buy Retell themselves.

That is why I built VoiceDash. It connects to your Retell account, pulls every agent's calls, recordings, transcripts, and usage, and gives each client a portal with your logo on your domain, scoped to only their own data. Live in under 10 minutes, no code, plans start at $19/mo with a 7-day free trial. VAPI and Bland support are coming soon; today it is purpose-built for Retell agents. The reporting principles are in voice AI client reporting, and the handoff that gets a new client to their first booked call is in how to onboard voice AI clients.

The bottom line

Split the work by who is waiting. If the caller is waiting, it is a mid-call function and it does exactly one thing fast. If nobody is waiting, it is a post-call webhook and it can do as much as you like. Verify signatures, make writes idempotent, build one template you duplicate per client, and keep the automation layer invisible while the results stay visible.

Want your clients to see the calls those workflows are booking, in a portal with your logo on your domain? Start free on VoiceDash or book a demo and I will walk you through the setup on a call.

FAQ

How do you connect Retell AI to n8n?

There are two connection points and they serve different jobs. The first is mid-call custom functions: you define a tool on the Retell agent that points at an n8n webhook URL, and during the call the agent calls it, waits for the response, and speaks the answer, which is how you get real calendar availability instead of invented times. The second is post-call webhooks: you set the agent's webhook URL to an n8n workflow and Retell posts call events to it, including the finished call with transcript and structured data. In practice you create the Webhook node in n8n first, copy the production URL into the Retell dashboard, place one test call, then build the workflow against the payload you actually received rather than a documented example, since field shapes change as Retell ships updates.

Should voice AI automation run during the call or after it?

Split the work by who is waiting. If the caller is sitting in silence while your workflow runs, it belongs in a mid-call function and it should do exactly one thing: query the calendar, check the service area, look up an existing customer, or reserve the slot the caller just accepted. One API call, a small JSON response, nothing else, because a four-second workflow makes the caller think the line dropped. Everything where nobody is waiting belongs in the post-call webhook: creating the CRM contact, attaching the transcript, sending the confirmation text, alerting the owner about an emergency, and logging the row for reporting. Most agents that feel broken are agents doing post-call work inside a mid-call function.

What are the most common Retell and n8n integration mistakes?

Five come up repeatedly. Putting slow work on the mid-call path, which makes an otherwise good agent feel broken. Skipping idempotency, so retried webhooks turn one call into three duplicate CRM records; check for an existing record by call ID or phone number before inserting. Parsing the transcript with string matching instead of reading the structured fields you asked the agent to collect, which breaks the first time a caller phrases something differently. Having no error branch, so failed writes stay silent until the client notices bookings are missing. And building each client's workflow from scratch instead of parameterizing one template you duplicate. Also verify the webhook signature, because that URL is a public endpoint that writes to a CRM.

Give your clients a dashboard with your name on it

VoiceDash turns your Retell agents into branded client portals. Live in under 10 minutes, no code.

Keep reading