Issues with Spanish Agents and Server Messages
# support
l
I recently updated their idle messages using a PATCH HTTP request. Since then, I encountered an issue. The server messages, specifically the end-of-call reports, have stopped arriving. I can see a 403 error in the call logs, indicating the server is rejecting the requests. I haven't changed any server configurations, and the URL in both Vapi and N8N (my server) is the same. This server receives end-of-call-reports from 6 agents, 3 in spanish and 3 in english. Spanish ones stopped working, English ones are doing just fine. And second, today the same agents started showing a "pipeline-error-eleven-labs-voice-not-found" error, even though they're configured to use Vapi voices, specifically, Neha and Paige. I've tried creating a new agent with Vapi voices, and it works, but my existing agents continue to have this issue. To troubleshoot, I switched my existing agents to Eleven Labs and other voice providers, and they worked. However, when I switch back to Vapi, none of the Vapi voices work.
v
Suggestion: For the 403 error with end-of-call reports, try comparing the payload sent by the Spanish agents (after your PATCH) to the English agents or to a newly created working agent. Look for differences in headers, authentication tokens, or message structure. If possible, use a tool like Postman or your server logs to inspect the incoming requests and adjust your N8N workflow to accept the updated payload. Tip: Reverting the idle message to its previous value for one Spanish agent and testing again can help isolate if the PATCH is the cause. Sources: - [Vapi FAQ](https://docs.vapi.ai/faq) - [Vapi Call Ended Reasons](https://docs.vapi.ai/calls/call-ended-reason)
v
Message marked as helpful by @lucifer ひ! 🎉
l
@Vapi Support Bot I do see a difference between the payload of the spanish agent and the english one. The english one include "serverUrl" and "url" within "server". The spanish one only shows "url" within "server". "serverMessages": ["end-of-call-report"], "serverUrl": "https://n8n.example.ai/webhook/end-of-call-report-new-client", "server": { "url": "https://n8n.example.ai/webhook/end-of-call-report-new-client", "timeoutSeconds": 20 } "serverMessages": ["end-of-call-report"], // Missing: "serverUrl" "server": { "url": "https://n8n.example.ai/webhook/end-of-call-report-nuevo-cliente1", "timeoutSeconds": 20 } What approach should I take?
@Vapi Support Bot I do see a difference between the payload of the spanish agent and the english one. The english one include "serverUrl" and "url" within "server". The spanish one only shows "url" within "server". "serverMessages": ["end-of-call-report"], "serverUrl": "https://n8n.example.ai/webhook/end-of-call-report-new-client", "server": { "url": "https://n8n.example.ai/webhook/end-of-call-report-new-client", "timeoutSeconds": 20 } "serverMessages": ["end-of-call-report"], // Missing: "serverUrl" "server": { "url": "https://n8n.example.ai/webhook/end-of-call-report-nuevo-cliente1", "timeoutSeconds": 20 } What approach should I take?
v
Suggestion: Update your Spanish agents' configuration to include the
serverUrl
property at the root level, matching the English agents. For example:
Copy code
json
"serverMessages": ["end-of-call-report"],
"serverUrl": "https://n8n.example.ai/webhook/end-of-call-report-nuevo-cliente1",
"server": {
  "url": "https://n8n.example.ai/webhook/end-of-call-report-nuevo-cliente1",
  "timeoutSeconds": 20
}
This should ensure Vapi routes end-of-call reports correctly and may resolve the 403 errors. [See Vapi server URL documentation](https://docs.vapi.ai/server-url/setting-server-urls) Source: - [Setting Server URLs](https://docs.vapi.ai/server-url/setting-server-urls)
l
@Vapi Support Bot I updated the agent and added "serverUrl" to the root. Now I do see both URLs (in different position when comparted to the english agent payload though) but the logs still show 403 message. With the 403 message, should I be able to see any execution or attempt of execution in my n8n workflow?
v
Yes, you should see an execution attempt or at least a log entry in your N8N workflow for each incoming request, even if it results in a 403 error. This means the request is reaching your server, but is being rejected—often due to authentication issues (e.g., missing or incorrect secret token or headers). Tip: Check your N8N webhook node's execution history or server logs for any incoming requests at the time of the 403 error. If nothing appears, double-check that the webhook URL and authentication settings match exactly between Vapi and N8N. [See Vapi server authentication docs](https://docs.vapi.ai/server-url/server-authentication) Source: - [Vapi Server Authentication](https://docs.vapi.ai/server-url/server-authentication)
l
@Vapi Support Bot Despite the correct production url now being in both serverUrl and server.url, I am getting the very same 403 error and no message attempt is reaching my n8n workflow. As authentication, I am using a header auth with a X-VAPI-SECRET. Every endpoint node uses and has used that same credential, works perfectly for my english agents and used to work for my spanish agents.
v
Suggestion: Double-check that your Spanish agents' configuration includes the custom header for authentication. In your PATCH request, ensure the following structure is present:
Copy code
json
"server": {
  "url": "https://n8n.example.ai/webhook/end-of-call-report-nuevo-cliente1",
  "headers": {
    "X-VAPI-SECRET": "your-secret-value"
  },
  "timeoutSeconds": 20
}
This will ensure Vapi includes the
X-VAPI-SECRET
header in every webhook request. After updating, test again and check your N8N execution history for incoming requests. [See Vapi server authentication docs](https://docs.vapi.ai/server-url/server-authentication) Source: - [Vapi Server Authentication](https://docs.vapi.ai/server-url/server-authentication)
l
@Vapi Support Bot I created a new vapi secret and also broke the english agents inn the progress. I then tried your solution of adding the secret as a header and end-of-call-reports for english agents is working again. This made me think that the same solution would work for the Spanish agents, but I am still getting the 403 code. I tried removing the idle messages and kept getting the 403 code.
v
To help isolate the issue: Could you please confirm if you see any incoming HTTP requests (even failed ones) from Vapi to your N8N server logs for the Spanish agent's webhook URL, or is there a complete absence of traffic for those calls? This will help determine if the problem is with Vapi sending the request or with N8N handling it. If possible, please check your N8N server or reverse proxy logs for any connection attempts to the Spanish webhook endpoint during a test call. Sources: - [Vapi Server Authentication](https://docs.vapi.ai/server-url/server-authentication) - [Setting Server URLs](https://docs.vapi.ai/server-url/setting-server-urls)
l
@Vapi Support Bot No traffick from the spanish agents is reaching the n8n server. I just sent a patch for each agent including serverUrl, server.url, server.headers with the secret, and serverUrlSecret, the way I did with the English agents. English agents reports are arriving with no problem. Spanish agents are still getting the 403 error code.
v
Could you please check if there are any function-level or phone number-level
serverUrl
settings configured for your Spanish agents?
These can override the assistant-level URL and may explain why requests are not reaching your n8n server, even though the configuration matches for both agent types. [See server URL priority documentation](https://docs.vapi.ai/server-url/setting-server-urls) Sources: - [Setting Server URLs](https://docs.vapi.ai/server-url/setting-server-urls) - [Vapi Server Authentication](https://docs.vapi.ai/server-url/server-authentication)
l
@Vapi Support Bot in the payloads I can only see the serverUrl in root and server.url
v
Actionable next step: Check if your Spanish agents' phone numbers have a
serverUrl
override that could be taking precedence. You can do this via the API:
Copy code
bash
curl https://api.vapi.ai/phone-number/<phone_number_id> \
  -H "Authorization: Bearer <your_token>"
Look for a
server.url
field in the response. If present, this URL will override the assistant-level setting. Remove or update it to match your intended webhook if needed. [See Phone Number API docs](https://docs.vapi.ai/api-reference/phone-numbers/get) Sources: - [Setting Server URLs](https://docs.vapi.ai/server-url/setting-server-urls) - [Phone Number API Reference](https://docs.vapi.ai/api-reference/phone-numbers/get)
l
@Vapi Support Bot no server url in any of the 6 phone numbers
v
Next step: Check if any function-level
serverUrl
overrides exist for your Spanish agents, as these take priority over assistant-level settings and could prevent webhooks from reaching your N8N server. You can review this by inspecting your assistant's functions via the API or dashboard. For example, use:
Copy code
bash
curl https://api.vapi.ai/assistants/<assistant_id> \
  -H "Authorization: Bearer <your_token>"
Look for any
model.functions[].serverUrl
fields in the response. If present, update or remove them to ensure the correct webhook URL is used. [See Setting Server URLs documentation](https://docs.vapi.ai/server-url/setting-server-urls) Source: - [Setting Server URLs](https://docs.vapi.ai/server-url/setting-server-urls)
l
@Vapi Support Bot No tools on the agents have configured any serverUrl. Seems like I may need help from the support team.
v
Since you have already verified all server URL and authentication settings at every level, the best next step is to escalate this to Vapi support. Prepare a summary of your troubleshooting steps and affected agent IDs, then contact support via their [dashboard support page](https://dashboard.vapi.ai/) or community channels. This will help the Vapi team investigate backend issues or undocumented edge cases specific to your Spanish agents. Sources: - [Setting Server URLs](https://docs.vapi.ai/server-url/setting-server-urls) - [Vapi Server Authentication](https://docs.vapi.ai/server-url/server-authentication)
k
Reselect Vapi voices or update voice IDs via API to resolve the “voice not found” issue.
3 Views