Help with Lead Qualification Workflow

Questions
1

I am troubleshooting a connection or handshake issue between Telnyx, Vapi, and n8n.
Context:
Telnyx phone number: +1-404-6
Use case: outbound AI voice agent for lead follow-up and qualification
Vapi is the voice agent platform
n8n Cloud hosts the automation workflow
Telnyx sends call events and webhooks to n8n
n8n processes the data and triggers downstream actions
Problem:
Calls place successfully, but call events, call logs, or webhook data are not consistently appearing where expected. In some cases, credentials appear saved, but the system does not fully authorize or trigger actions. This suggests a handshake or authorization issue between platforms.
What I need help with:
Verifying the Telnyx number is correctly assigned to a single outbound application and not bound to another connection
Confirming webhook delivery from Telnyx to n8n, including endpoint, method, and response codes
Validating API key scope and permissions for Telnyx and Vapi
Confirming whether inbound call settings or voice application routing are blocking outbound event visibility
Identifying any known issues with Telnyx outbound call events, CDR visibility, or webhook delays
Confirming the correct order of authorization between Telnyx, Vapi, and n8n
Goal:
Ensure a clean, reliable handshake so outbound calls trigger call events, logs, and workflow execution consistently across Telnyx, Vapi, and n8n.

2

Hi @Beluvedone Welcome!
For reliable lead‑qualification calls point Telnyx’s connection or AI assistant to the exact n8n webhook URL used in your workflow (POST, public, returns 200) verify in Telnyx’s Debugging/Webhooks that events hit that URL without timeout or failure, then configure Vapi’s call event/webhook URL to that same n8n endpoint so that Telnyx → Vapi → n8n all share a single reachable webhook path and you can see every call event and CDR logged

3

Thank you for the initial guidance. I’ve refined the workflow based on your advice, but I’m hitting a specific technical wall in n8n Cloud regarding the handshake.

Current Setup Update:

  • Webhook Configuration: I have a single reachable n8n POST endpoint (Production URL) configured in Vapi.

  • Response Settings: The n8n Webhook node is set to ‘Respond: Immediately’ with an HTTP 200 status code.

  • Error Log: Despite this setting, my n8n execution logs consistently show a ‘Failed’ status with the specific error: “No Respond to Webhook node found in the workflow”

Error Handler successfully catches these crashes, confirming n8n receives the hit, but the handshake fails to ‘close’ with Vapi/Telnyx.. The goal now is to confirm if this is a known Cloud bug or if a physical ‘Respond to Webhook’ node is mandatory despite Trigger settings.

4

@Beluvedone I guess now you can do 2 things, 1st switch your Webhook node’s Respond mode from “Using ‘Respond to Webhook’ node” to “Immediately” and see where it takes, 2nd keep “Using ‘Respond to Webhook’ node” and add a Respond to Webhook node wired into the main execution path so every Telnyx/Vapi hit reaches it and returns the 200 handshake cleanly. I am not very well aware about that is this a cloud bug or not, let me know what works.

5

I agree with Anshul’s Analysis. This is not a Telnyx or Vapi authorization issue. It’s an n8n webhook response-mode mismatch.

The webhook does reach n8n (executions start), but some executions never return an HTTP response. When that happens, n8n marks the run Failed, the webhook handshake isn’t closed, and Telnyx/Vapi treat the event as failed or retry it. Only executions that reach a response succeed — which is why it “sometimes works.”

Telephony platforms expect a fast, deterministic 200 OK and don’t wait for downstream workflow logic.

Fix: Pick one and make it deterministic

Recommended for telephony — Respond Immediately

  • Webhook node: Respond = Immediately

  • HTTP code: 200

  • No Respond to Webhook node

  • Downstream logic runs async

Alternative — Using Respond to Webhook

  • Webhook node: Using Respond to Webhook

  • Add a Respond to Webhook node

  • Every execution path, including error paths, must reach it

  • Any missed path causes intermittent failure

Do not mix the two patterns.

Sanity check

Outside of N8N call the Production webhook URL used by Vapi:

curl -i -X POST https://<n8n-cloud-url>/webhook/<path> \
  -H "content-type: application/json" \
  -d '{"test":"ping"}'

You should get an immediate 200 OK and no failed execution.

References

6

Hi @Beluvedone , welcome to the n8n community :tada: !
See if this documentation can help you:
[Webhook to Vapi; Webhook to Vapi solved
MCP trigger with Vapi
HTTP 401 auth
(Credential problems in node HTTP Request from n8n to Vapi)
FB Lead Ads pending

1 Like
7

Hi there,

This sounds like a “middleman” configuration issue. Since Vapi is handling the voice agent logic, but you are looking for raw Telnyx webhooks in n8n, there is often a conflict in where the “Call Control” is pointing.

Here is a checklist to isolate the handshake break:

1. Isolate the Webhook Sender (Telnyx vs. Vapi)

When using Vapi, Vapi usually takes over the Telnyx Call Control Application.

If you need call status/transcripts: You should typically rely on Vapi’s webhooks (Server URL), not Telnyx’s. Configure your n8n Webhook URL inside the Vapi Dashboard (under Assistants → Server URL). Vapi aggregates the events and sends a clean JSON payload to n8n.

If you absolutely need raw Telnyx data: Ensure your Telnyx Portal → Call Control / Applications → Webhook URL is pointing to n8n. Note that if Vapi is also trying to control the call via SIP, having a separate webhook listener on the Telnyx side can sometimes lead to race conditions if not scoped correctly.

2. Verify the “Handshake” with Webhook.site

Before debugging n8n, rule out the platform delivery:

Create a temporary URL on webhook.site.

Paste that URL into your Telnyx (or Vapi) webhook settings.

Make a test call.

Result: If data hits webhook.site but not n8n, the issue is your n8n node configuration (likely authentication or HTTP method). If it doesn’t hit webhook.site, the issue is upstream in Telnyx/Vapi permissions.

3. Common Telnyx Gotchas

HTTP Method: Telnyx sends POST requests. Ensure your n8n Webhook node is set to POST.

Profile Assignment: Double-check that the specific phone number in Telnyx is assigned to the correct “Messaging Profile” or “Call Control App” that contains your webhook URL. It’s common to have the webhook set on the Account level but the number assigned to a Profile that overrides it.

4. Check n8n Execution Mode

Are you testing with the Production webhook URL or the Test webhook URL?

If you are looking at the n8n editor canvas, you must use the …/webhook-test/… URL and have the “Listening” window open. If you use the production URL, the data won’t show in the canvas live view; it will go straight to the Execution Log.

Let us know if the webhook.site test reveals anything—that usually pinpoints the culprit immediately

8

Hi Everyone - I want to thank you all for your input, which helped me refine my workflow. Here’s a quick update on the current status and some challenges I faced, particularly with Google Sheets reporting.

Workflow Status: The workflow is live and successfully capturing Vapi end-of-call report webhooks. My Vapi assistant is engaging with prospects, and data is flowing into my master log.

Key Changes:

  1. Deep Memory JavaScript: I switched to a Code Node to prevent “data amnesia” from the Wait Node. Structured Outputs: Implemented a strict JSON Schema to extract key properties for better data cleanliness.

  2. Increased Wait Time: The Wait node was increased from 10 to 50 seconds for more time during the “Analysis” phase.

  3. Debugging: The “Copy to Editor” feature has been crucial for testing JavaScript logic.

Challenges: I faced 400 Bad Request errors due to column header changes in Google Sheets. The solution involves manually refreshing the Google Sheets node parameters and remapping fields. I’m also refining the logic to avoid duplicate rows for returning prospects.

Thanks again for your support!

Dave

10

I’m struggling to map Vapi’s End-of-Call Report to a Google Sheet. Vapi successfully captures structured data (Name, Email, Rating), but my n8n Code node fails to “find” these values, returning my fallback “Unknown Veteran” values instead.

Tool Stack: Vapi → n8n → Google Sheets.

The Issue: Vapi nests data inside body.message.analysis.structuredData.result. Despite trying various JS paths (including .result and case-sensitive checks), the variables remain undefined in the n8n output panel.

Current JS Logic: item.json.vapi_name = structured.lead_name || "Unknown Veteran";

Need Help With: Correctly referencing the nested JSON path from the Vapi webhook payload to stop it from defaulting to the fallback values.

11

The Stack: Vapi (Voice AI) → n8n (Cloud) → Google Sheets

The Problem: The data is nested deeply in the Vapi payload. Even after confirming lowercase keys and attempting to access the .result object, the variables remain undefined.

JSON Structure from Vapi: The data lives at: body.message.analysis.structuredData.result Keys: lead_name, lead_email, current_rating

Current JavaScript Snippet: const webhookData = $(‘Respond to Webhook’).item.json;
const body = webhookData.body?.message || {};
const analysis = body.analysis || {};

// Trying to access the nested result folder
const structured = analysis.structuredData?.result || analysis.structuredData || {};

item.json.vapi_name = structured.lead_name || “Unknown Prospect”;
return item; The Issue: The Output panel consistently shows “Unknown Veteran.” It seems the Code node isn’t “seeing” the data from the Webhook trigger node correctly, or my pathing to the result object is flawed.

Need Help With: 1. Correctly referencing the JSON path from the Webhook trigger. 2. Ensuring the data survives the “Wait” node before the Code node.