ElevenLabs Agents Integrations: What Each One Actually Requires

ElevenLabs Agents connect to external systems in five main ways: native telephony, built-in app integrations, webhook tools, MCP servers, and client-side SDKs. Each comes with its own setup requirements, and its own failure points.

In most voice agent projects, the voice itself is not the problem. The real challenge is the plumbing. An agent may sound great in the dashboard but still be unable to check a calendar, update the CRM, or transfer a caller to a human.

This guide covers the integration paths businesses actually use. For each one, we explain what needs to be in place before it works and where things are most likely to go wrong during a live call.

Layer3 Labs may earn a referral commission if you sign up through some links on this page, at no extra cost to you. Commissions never change our verdicts.

How ElevenLabs Agents Connect to Other Systems

An agent reaches the outside world through tools, and there are four kinds. System tools are built in, webhook tools call your own HTTP endpoints, client tools fire events inside your app, and MCP servers expose a whole tool catalogue at once.

System tools cover the call-control jobs. The vendor documents end call, language detection, agent transfer, transfer to number, skip turn, keypad touch tones, voicemail detection, and update state.

Everything else is something you wire yourself. The agent decides when to call a tool based on the tool name, the description, and your system prompt. A vague description is the single most common reason a tool never fires.

• System tools: built-in call control, including transfer and language switching.
• Webhook tools: your REST endpoints, with headers, path, query, and body parameters.
• Client tools: browser or app-side actions, not server calls.
• MCP servers: a third-party tool catalogue connected in one step.
• Native integrations: prebuilt connectors for calendars, CRM, and telephony.

Telephony: Twilio, SIP Trunking, and Outbound Batches

There are two ways to put an agent on a phone line: the native Twilio integration or a SIP trunk. Twilio is the fastest path, and SIP is the one you use when you already own a phone system.

The native Twilio route needs a Twilio account, a purchased number, and your Twilio credentials stored in the agent platform. You then assign the number to an agent for inbound calls.

SIP trunking connects an existing PBX or carrier instead. The vendor lists compatibility with standard SIP providers including Twilio, Vonage, RingCentral, Telnyx, Plivo, Bandwidth, Sinch, Infobip, and Exotel. For outbound campaigns, batch calling triggers many calls at once against a recipient list.

The practical requirement most teams miss is number provenance. Caller ID, local presence, and regional routing are your telephony provider's job, not the agent platform's.

• Native Twilio: account, purchased number, credentials, number assigned to an agent.
• SIP trunk: your own carrier, SIP credentials, and firewall or IP rules on your side.
• Batch calling: a recipient list plus an agent and an outbound-capable number.
• Regional routing exists for Twilio numbers where data residency matters.

Warm Transfer to a Human

Transferring a caller to a person uses the transfer to number system tool, and it works with both Twilio numbers and SIP URIs. You configure the destination, the condition, a message for the caller, and a message for the person receiving the call.

The default method is a conference transfer. The platform dials the destination, joins everyone into a conference room, then drops the AI agent so only the caller and the human remain.

The alternative is a SIP REFER transfer, which hands the call straight to the destination. It only works when the conversation is running over SIP, and your trunk has to allow transfer via SIP REFER.

One failure mode to plan for: the destination does not answer. Decide in advance whether the agent stays on the line, takes a message, or falls back to a second number.

• Conference transfer: default, works on Twilio and SIP, agent leaves after connecting.
• SIP REFER: SIP-only, and your trunk must permit REFER.
• You must supply both a caller message and an agent-to-human handoff message.
• Test the no-answer and busy paths before launch, not after.

Automation: n8n, Zapier, Make, and Webhooks

Automation platforms connect in two directions, and it helps to keep them straight. During a call, the agent calls out through a webhook tool. After a call, the platform pushes a post-call webhook to you.

The vendor's integrations directory lists Zapier, n8n, and Make under automation. In practice an n8n or Make workflow is just an HTTPS endpoint that you register as a webhook tool, with authentication headers.

Post-call webhooks are the reliable place to do slow work. The vendor documents three types: full transcription with analysis, audio as base64 MP3, and call initiation failure events.

Two requirements matter here. Your endpoint must return a 200 status code, and you should verify the HMAC signature on the ElevenLabs-Signature header before trusting the payload.

• In-call actions: webhook tools, kept fast so the caller is not left waiting.
• After-call actions: post-call webhooks for CRM writes, emails, and reporting.
• Authentication: HMAC signature verification, with optional IP allowlisting.
• Repeated delivery failures can auto-disable a webhook, so monitor your endpoint.
• Sending an email is not a native feature. Route it through an automation platform or your own endpoint.

MCP: Connecting a Whole Tool Server at Once

MCP lets an agent use every tool on an external server without you defining each one by hand. That speed is also the risk, because you are handing a live phone agent a tool catalogue you did not write.

The platform provides three approval modes. Always Ask requires permission for every tool call, Fine-Grained Tool Approval sets rules per tool, and No Approval allows unrestricted use.

The vendor is direct about responsibility: you are responsible for the security, compliance, and behaviour of any third-party MCP server you connect. Its guidance is to start with Always Ask and only loosen it after testing.

For a voice agent, treat write actions differently from read actions. Auto-approve lookups, require approval for anything that charges a card, cancels an order, or changes a record.

• Always Ask: safest, but adds a confirmation step to every tool call.
• Fine-grained: auto-approve read-only tools, gate write tools, disable the rest.
• There is also a hosted MCP server for managing agents from an MCP client.
• Review what each exposed tool can access before you connect the server.

Calendar and Booking: Google Calendar and Cal.com

Booking is a native integration, not something you have to build. Google Calendar connects through Google OAuth 2.0, and Cal.com has its own connector for scheduling.

The Google Calendar integration requests three scopes: manage events on calendars you own, view your calendar list, and check free or busy availability. Free/busy access means the agent can see that a slot is taken without reading the event details.

The booking flow runs as a sequence of tool calls. The agent lists calendars, checks availability, collects the attendee name and email, confirms the time zone, then creates the event.

The weak link is the email address. It arrives as transcribed speech, so the vendor's own example prompt tells the agent to read it back before booking. Build that confirmation step in or expect wrong invites.

• Google Calendar: OAuth connection, calendar-owner account, three scopes granted.
• The agent can add a Google Meet link when video is requested.
• Time zone must be collected in Continent/City format for reliable booking.
• Cal.com is the alternative native scheduling connector.

CRM Handoff: HubSpot, Salesforce, and Structured Data

CRM handoff needs two pieces: a connection to the CRM, and structured data worth sending. The vendor ships native connectors for HubSpot and Salesforce, and its directory also lists Zoho, Pipedrive, Monday.com, Zendesk, and ServiceNow.

The data side is the part teams forget. Conversation analysis includes a data collection feature that extracts structured fields from the transcript using an LLM, so you get a name and an intent rather than a wall of text.

The vendor documents a per-agent cap on data collection items, higher on Trial and Enterprise plans than on other plans. Check the current figures on the vendor page before you design a large field set.

The clean pattern is: collect fields during the call, write to the CRM from the post-call webhook. That keeps CRM latency and CRM outages away from the live conversation.

• Native connectors: HubSpot and Salesforce; others available through webhook tools.
• Data collection turns transcripts into typed fields you can map to CRM properties.
• Success evaluation returns success, failure, or unknown with a written rationale.
• Write to the CRM after the call so a slow CRM never stalls a caller.

Knowledge Base and RAG Wiring

The knowledge base is how the agent answers questions about your business without you writing every answer into the prompt. It accepts PDF, DOCX, TXT, MD, HTML, and EPUB files, documented at up to 20MB per file.

There are two retrieval modes. Small documents can sit in the system prompt directly, while larger ones need RAG, which retrieves only the relevant chunks per question.

The vendor documents a rough full-context ceiling of about 300,000 characters per document, and a 2MB maximum system prompt that includes instructions and knowledge base content. Folders are always accessed through RAG, so RAG must be enabled to use them.

The cost of RAG is time. The vendor states it adds around 250ms to response time. On a phone call that is a real quarter second, so index only what the agent genuinely needs.

• Supported files: PDF, DOCX, TXT, MD, HTML, EPUB, up to 20MB each.
• Documents over roughly 300,000 characters must use RAG, not full context.
• RAG adds about 250ms of latency per the vendor's own docs.
• Google Drive sync is available to keep knowledge base files current.

Using a Custom LLM Instead of the Built-in Models

You can point an agent at your own model instead of the hosted ones. The vendor describes it as providing the endpoint to make requests to, plus credentials held in its secure secret storage.

The endpoint has to speak an OpenAI-compatible format. For reasoning models, the docs describe streaming reasoning in the reasoning or reasoning_content field of each response delta, or returning a reasoning output item on the Responses API.

There are two honest reasons to do this. You have a fine-tuned model that outperforms the stock options on your domain, or you have a compliance rule about where inference runs. Custom LLMs stay available even with EU data residency enabled.

The tradeoff is that latency becomes your problem. Time to first token drives how fast the agent starts speaking, and a slow self-hosted endpoint will make a good voice sound sluggish.

• Requires an OpenAI-compatible endpoint plus stored credentials.
• Hosted options include models from ElevenLabs, Google, OpenAI, and Anthropic.
• System prompt cap is 2MB including knowledge base content.
• Your endpoint's time to first token becomes the agent's response delay.

WhatsApp, Chat Mode, and SMS

The same agent can run as text, not just voice. Chat mode makes a conversation text-only, either through the widget's text input or by enabling a text-only toggle on the agent itself.

WhatsApp is a separate connection. You import an existing WhatsApp business account, authorise the platform to manage it, then assign an agent to it in settings.

The requirement that catches people out is assignment. If no agent is assigned, inbound messages are ignored and inbound calls are rejected. Voice calling and outbound calling also need configuration on the WhatsApp side, including a payment method for outbound.

SMS runs through Twilio rather than WhatsApp, and the docs also cover SMS one-time passcode verification during a conversation for identity checks.

• Chat mode: text-only conversations from the same agent configuration.
• WhatsApp: import a business account, authorise, then assign an agent.
• Messaging can be toggled off so your own app handles chat while the agent handles calls.
• SMS and SMS OTP verification run through the Twilio integration.

The SDKs: React, React Native, Python, JavaScript, Swift, and Kotlin

The official client libraries listed in the vendor's documentation index are Python, JavaScript, React, React Native, Swift, and Kotlin, plus a raw WebSocket interface. The dashboard's own test panel runs on the React SDK.

Pick by where the microphone lives. React and JavaScript cover the web, React Native covers cross-platform mobile, Swift covers iOS, Kotlin covers Android, and Python covers server-side and outbound work.

Worth knowing before you plan a mobile build: there is no official Flutter SDK in that index at the time of writing. A Flutter app has to go through the WebSocket interface or a community wrapper, which is a real amount of extra work.

For a plain website, you may not need an SDK at all. The embeddable widget is an HTML snippet with an agent ID, and it is the fastest way to test with real users.

• Web: JavaScript or React SDK, or the copy-paste widget snippet.
• Mobile: React Native, Swift, or Kotlin.
• Backend and outbound calling: the Python SDK.
• No official Flutter SDK listed; plan for WebSocket work if Flutter is your stack.
• Confirm the current library list on the vendor docs before you commit a roadmap.

What Each Integration Requires, Side by Side

The table below is the short version of everything above: the one thing you must have in place before each integration will work. Use it to spot the blockers before a build starts, not halfway through.

The pattern across all of them is credentials plus a clear trigger. Nearly every stalled build we see is missing one of those two things.

Vendor features change often. Treat this as a starting checklist and confirm the current requirements on the vendor's documentation.