t/ghl-make-retell/806) .

### Answer Yes, GoHighLevel (GHL) has a native integration as a supported CRM provider [(1) ]() . Through this native connection, your agents can look up and manage contacts, opportunities, and tasks, add tags, create notes, and check availability and book, reschedule, or cancel appointments on GHL calendars . Authentication is via API key plus the sub-account Location ID . Regarding limitations, a connection error on GHL specifically can be tricky to diagnose: a missing scope on GoHighLevel comes back as an authorization error that Retell can't distinguish from a dead token, so a tool call can flag the connection as broken even though the credentials are technically fine . As for what still requires Make/N8N: broader Google Workspace tasks (Gmail, Docs, Sheets, Calendar) aren't part of Retell's native integrations list , and Discord community discussion confirms the recommended workaround is routing through Make, N8N, or Zapier with custom API calls for that kind of workspace automation [(2) ]() . A separate community thread also notes that a dedicated GHL node for platforms like Make was mentioned as "live" by a Retell team member, with N8N and HubSpot nodes described as pending approval at that time, though users in that thread reported difficulty locating the GHL node in the functions section [(3) ]() . Additionally, a community troubleshooting post describes a workflow combining GHL, Make, and Retell together to pull calendar availability and inject it into a Retell call via variables — suggesting that even with native GHL support, some users still add Make in the middle for tasks like syncing dynamic call variables from calendar data [(4) ](

​ To learn more, see the sources I considered: [[1] Integrations overview](https://docs.retellai.com/integrations/overview) [[2] Google Workspace integration?](https://discord.com/channels/1186424376300679209/1378444478842409020) [[3] Native Integrations for Top Platforms](https://community.retellai.com/t/native-integrations-for-top-platforms/160) [[4] GHL + Make + Retell](https://community.retellai.com/t/ghl-make-retell/806) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

Thanks for the feedback, glad I was helpful.

### Answer There's no official recommended flow or diagram in the available sources that prescribes one pattern over the other for combining an inbound call webhook with Agent Transfer when GoHighLevel is the system of record. What the sources do establish: The inbound call webhook fires at the very start of a call and returns key-value pairs that become dynamic variables the LLM can use, such as a contact's name looked up from their phone number [(1) ]() . This means the webhook itself is capable of doing a GoHighLevel contact lookup and injecting that data into whichever agent picks up the call — but the sources don't state that the webhook can route the call to a different specialist agent; the webhook response is described only as supplying dynamic variables to the agent already handling the call . Agent Transfer, by contrast, is documented as the mechanism for handing a live call from one AI agent to another mid-conversation, with the destination agent inheriting the full conversation history, call-level metadata, and dynamic variables (both those passed at call start and any extracted during the call) [(2) ]() . It's explicitly positioned for modularizing a long or branching flow, reusing specialized agents, or switching based on information learned during the call — for example, transferring once you know the task, such as moving from a front-desk agent to an appointment-booking agent . Given only what's documented: a front-door agent using Agent Transfer to hand off to specialists is a supported and described pattern , since Agent Transfer is built for exactly that kind of task-based routing after the call has started. Whether the webhook itself can route directly to a specialist agent based on a GHL lookup isn't addressed in the sources — the we

bhook's documented role is supplying variables at call start, not selecting which agent handles the call [(1) ]() . For the GoHighLevel-specific side, the native integration supports contact lookups, tagging, opportunities, and calendar booking within a connected agent [(3) ]() , but the sources don't describe combining that lookup with agent selection at the webhook stage. I don't have documentation confirming an official best-practice architecture here. Check out these potentially relevant sources: [Agent Transfer tool: hand a call to another AI agent]() , [Connect GoHighLevel]() , [Live Workshop: Retell x GoHighLevel Integration]() . Want a general answer based on common patterns instead?

​ To learn more, see the sources I considered: [[1] Live Workshop: Retell x GoHighLevel Integration]() [[2] Agent Transfer tool: hand a call to another AI agent](https://docs.retellai.com/build/single-multi-prompt/transfer-agent) [[3] Connect GoHighLevel](https://docs.retellai.com/integrations/gohighlevel) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

### Answer Yes — the inbound call webhook response supports a

dynamic_variables

field, which lets you set dynamic variables for the inbound call at the point the webhook responds [(1) ]() . Since the webhook can perform a lookup (e.g., against a CRM/database) before the call starts and then return that contact data as

dynamic_variables

, those values are available to the agent from the start of the call as variables it can reference in the prompt [(2) ]() , [(3) ]() . For example, the community Discord guidance describes this exact flow: use the inbound webhook to get the caller's phone number before the call starts, look them up, and send the information back to the agent as a dynamic variable, referenced in the prompt like

Hello {{user_name}}

[(2) ]() . This means the agent doesn't need to wait for the caller to speak — the looked-up data is already injected as a variable before the call begins . Regarding whether a second native Search Contact lookup is required mid-call: the sources don't state that GoHighLevel's Search Contact tool can accept or reuse a contact record injected via the webhook's

dynamic_variables

. The GoHighLevel agent functions documentation describes Search Contact as finding a contact by phone number to identify the caller, and other tools (Get Contact, Update Contact, etc.) working off a contact ID typically obtained from that Search Contact call [(4) ]() . Nothing in the sources describes passing a webhook-provided contact ID directly into these tools to skip a mid-call Search Contact invocation. So th

e pattern of passing the webhook lookup forward as

dynamic_variables

is documented and supported [(1) ]() , [(2) ]() , but whether that eliminates the need for a second native Search Contact call depends on whether your prompt/flow is designed to reference the dynamic variable (e.g., a contact ID) instead of invoking the tool again — the sources don't explicitly confirm or rule out feeding a dynamic variable into Search Contact's tool config to bypass a second lookup [(4) ]() . I don't have documentation confirming this exact integration detail. Check out these potentially relevant sources: [Inbound call & SMS webhook]() , [GoHighLevel agent functions]() , [Discord message from @omar.13. on 2026-01-13]() . Want a general answer based on common patterns instead?

​ To learn more, see the sources I considered: [[1] Inbound call & SMS webhook](https://docs.retellai.com/features/inbound-call-webhook) [[2] Discord message from @omar.13. on 2026-01-13](https://discord.com/channels/1186424376300679209/1186462578310910112/1460732410248564880) [[3] Live Workshop: Retell x GoHighLevel Integration]() [[4] GoHighLevel agent functions](https://docs.retellai.com/integrations/gohighlevel-functions) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

### Answer I don't have documentation stating a specific numeric threshold or official rule for when splitting into multiple narrow-specialist agents becomes "too many" versus keeping everything in one Conversation Flow agent. What the sources do establish are the mechanics and stated rationale behind each approach, which offer some indirect guidance: Case for a single Conversation Flow agent: Conversation flow agents are designed to handle complex scenarios within one agent by breaking work into nodes (dialogue, tool-calling, logic, transfer, etc.) connected by transition conditions [(1) ]() . The documented benefit of this structure is that you can "change one part of the flow without touching the rest" [(2) ]() , and node types like the Subagent Node support multiple tools while staying active across multiple turns before transitioning . This suggests a single flow can absorb considerable complexity (receptionist, booking, reactivation logic) as separate nodes rather than separate agents, provided the logic is manageable within that graph. Case for splitting via Agent Transfer: Agent Transfer is documented as being "useful for specialized agents, language switches, and modular call flows" [(3) ]() , letting you "modularize tasks and re-use specialized agents" . The stated advantages are near-instant transitions, no new phone call, no handoff message needed since the destination agent inherits full conversation history, and no separate phone numbers required per agent [(3) ]() [(4) ]() . The docs also note you can chain transfers (A → B → C)

and even transfer back to a previous agent, with no fixed cap on the number of transfers per call — the only constraint is that a new transfer can't start while another is in progress [(4) ]() . A relevant signal from the Nodes and edges documentation is its guidance on when to break down a single node — which, while not directly about splitting into separate agents, reflects the same underlying philosophy: "Consider breaking down a node when: The node handles multiple complex logic paths, the LLM struggles with consistency (hallucinations or incorrect responses) , you need different settings (model, temperature) for different parts, [or] the conversation flow becomes hard to follow or debug" [(2) ]() . It adds that "breaking complex nodes into smaller, focused nodes often improves reliability" . Since Agent Transfer exists specifically to let you reuse specialized agents and switch settings like language, voice, or model per agent [(3) ]() [(4) ]() , the same reasoning would extend to justifying separate agents when the specialists genuinely need distinct configurations (e.g., different voices, models, or prompt scopes) rather than just distinct topics. I don't have documentation confirming a specific threshold or a builder consensus beyond this. Check out these potentially relevant sources: [Nodes and edges]() , [Agent Transfer tool: hand a call to another AI agent]() , [Conversation flow agents: structured voice AI call control]()

. Want a general answer based on common architecture patterns instead?

​ To learn more, see the sources I considered: [[1] Conversation flow agents: structured voice AI call control](https://docs.retellai.com/build/conversation-flow/overview) [[2] Nodes and edges](https://docs.retellai.com/build/conversation-flow/node) [[3] Agent Transfer Node](https://docs.retellai.com/build/conversation-flow/transfer-agent-node) [[4] Agent Transfer tool: hand a call to another AI agent](https://docs.retellai.com/build/single-multi-prompt/transfer-agent) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

Thanks for the follow-up, @GigoDA. I'll get back to you soon.

m_number` regardless of how the call arrived. I don't have documentation confirming whether carrier-level forwarding preserves or rewrites the original caller's number in Retell's `from_number`/`{{user_number}}`. Since this is carrier-specific behavior (how your carrier and Orca's carrier handle forwarded caller ID over the PSTN) , it's worth testing directly with a real call from a known number through the forwarded path and checking the inbound webhook payload and

{{user_number}}

value. Check out these potentially relevant sources: [Inbound call & SMS webhook]() , [Dynamic variables: personalize Retell agent calls]() , [Inbound call webhook doesn't contain from_number 😰]() . Want a general answer based on common telecom forwarding behavior instead?

​ To learn more, see the sources I considered: [[1] Inbound call & SMS webhook](https://docs.retellai.com/features/inbound-call-webhook) [[2] Dynamic variables: personalize Retell agent calls](https://docs.retellai.com/build/dynamic-variables) [[3] Inbound call webhook doesn't contain from_number 😰](https://discord.com/channels/1186424376300679209/1385012238431293461) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

### Answer There's no documented native GHL workflow trigger for outbound Retell calls in these sources — the closest documented pattern is HubSpot workflows, which have a dedicated "Make a Phone Call" action added directly in the HubSpot workflow builder after installing the Retell integration [(1) ]() . Nothing in these sources describes an equivalent native GHL workflow action for outbound calls. For GHL specifically, the available community guidance points to a webhook-based workaround rather than a native trigger: using a "custom webhook" function in GHL to trigger calls, calling Retell's Create Call API [(2) ]() . This matches a similar pattern discussed for other platforms: creating a custom webhook (e.g., in Make.com) that posts to Retell, then using that webhook URL to trigger calls [(3) ]() . On the Retell API side, the documented mechanism for triggering an outbound call is the Create Phone Call endpoint:

curl --request POST \
  --url <https://api.retellai.com/v2/create-phone-call> \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: application/json' \
  --data '
{
  "from_number": "+14157774444",
  "to_number": "+12137774445",

[(4) ]() So based strictly on these sources: a GHL workflow triggering an outbound Retell call has to go through a Custom Webhook action in GHL that calls Retell's Create Phone Call endpoint [(4) ]() [(2) ]() — there's no documented native "trigger outbound call" action inside GHL workflows themselves, unlike the native action documented for HubSpot [(1) ]() . I don't have documentation confirming whether GHL's marketplace app (referenced in [(2) ]() as supporting appointment booking) includes any outbound-call-triggering action beyond this webhook workaround.

​ To learn more, see the sources I considered: [[1] Trigger Retell calls from HubSpot workflows](https://docs.retellai.com/integrations/hubspot-marketplace) [[2] Getting a 400 error from the GoHighLevel Marketplace](https://discord.com/channels/1186424376300679209/1336434583922540605) [[3] Can we do do outbound call through webhook?](https://discord.com/channels/1186424376300679209/1339913408035815424) [[4] Create Phone Call](https://docs.retellai.com/api-references/create-phone-call) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

### Answer I don't have documentation confirming whether the native GHL functions (Get Contact, Update Contact, Create Note) accept a

contact_id

passed directly from a dynamic variable, or whether they require a Search Contact call first in the same session. None of the available sources describe the internal input requirements of those specific GHL functions in that level of detail. The sources here cover the inbound call webhook's

dynamic_variables

mechanism [(1) ]() , GoHighLevel contact sync behavior for imported contacts [(2) ]() , and unrelated Discord threads about dynamic variable delivery issues [(3) ]() [(4) ]() [(5) ]() — none of which state whether Get Contact, Update Contact, or Create Note can take a contact ID directly as an argument versus requiring a Search Contact lookup first. Check out these potentially relevant sources: [Inbound call & SMS webhook]() , [GoHighLevel contact sync]() . Want a general answer based on common patterns instead?

​ To learn more, see the sources I considered: [[1] Inbound call & SMS webhook](https://docs.retellai.com/features/inbound-call-webhook) [[2] GoHighLevel contact sync](https://docs.retellai.com/integrations/gohighlevel-contact-sync) [[3] Inbound call webhook doesn't contain from_number 😰](https://discord.com/channels/1186424376300679209/1385012238431293461) [[4] Dynamic Variables Not Returning To The Agent](https://discord.com/channels/1186424376300679209/1347902728617328741) [[5] Inbound Dynamic Variable Webhook not being received](https://discord.com/channels/1186424376300679209/1329515648367333506) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.