https://vapi.ai/ logo
Join Discord
Powered by
Vapi assistant request bouncing from multiple exte...
# support
o
Hi team, Further to our ticket submitted over the weekend which we still haven't heard anything back on. We have further identified the problem. It appears our serverURL is not being set correctly as vapi is sending the assistant request to the wrong serverURL sometimes and other time to the correct one. Can someone please explain why on earth the serverURL being used is changing and can we please on your end, set our organisation serverURL to "" and clear any other server URLs of our organisation "Optiphone Innovations" including all phone number and assistant serverURLs. We have previously raised support requests in discord for serverURLs not working correctly and we never heard from vapi support. Community users tried their best to support but ultimately we were left with no solution. This is quite frustrating and I'd really appreciate a response as it's now been two working days and three calendar days since we submitted this ticket and we have not heard anything either. In the meantime, our transient agents are completely disabled until you can fix this. I look forward to your response. Thank you, Dylan Amey
v
To clear a server URL for a phone number via the API, you can use the following PATCH request (replace 
{id}
with your phone number's ID):
Copy code
http
PATCH /phone-number/{id}
Content-Type: application/json

{
  "server": { "url": "" }
}
Repeat this for each phone number, assistant, and at the organization level to ensure all server URLs are cleared. For more details on server URL priority and configuration, see the [Vapi documentation](https://docs.vapi.ai/server-url/setting-server-urls). Sources: - [Setting server URLs](https://docs.vapi.ai/server-url/setting-server-urls) - [Personalization with user information](https://docs.vapi.ai/assistants/personalization)
o
Hi team, Thank you for your response. We’ve tried this and it didn’t work. Additionally this isn’t an option for organisation serverURLs which we believe is the actual issue. We have tried clearing the serverURL of assistants and phone numbers, even deleting old assistants and phone numbers to ensure they were cleared correctly. But updating the serverURL through the UI for organisations doesn’t seem to be reliable and I couldn’t find any way to update this via the api even in my previous support ticket.
For added context, we’ve switched our serverURL from an old automation on a different platform. I beleive this switch is what isn’t being recognised so when “the server rejects our assistant request” I believe it’s sending the request to the wrong serverURL
c
Please provide your org id and we will clear the serverUrl on the org level
o
Amazing thank you so much! I assume this will be censored As I'm aware you post these online to help others with the same issues. My org ID is: e83fcbb4-b18f-4a56-ad2b-e7bedfc060f5
@User Hi just checking someone is still going to action this? Sorry for my late response
c
ServerUrl has been cleared on the org level. Let us know if you have any questions
o
Hi team. Thank you for getting back to me. Firstly, thank you for clearing the serverURL. Unfortunately I hoped this would solve the issue but our webhook is still often not receiving the assistant request when calls are received. We have setup the serverURL since you cleared it and still we get the "your server rejected assistant request webhook error" message. Yet our n8n flow never actually even receives the request. As briefly discussed I thought this was an issue with the setup of the ServerURL but it isn't working at all now. What information would you like me to provide to assist in troubleshooting this as we cannot use our transient assistants currently. I will try again tomorrow morning, hopefully it just takes time for the serverURL to propogate. As a reminder, we have no other serverURLs set on the organisation, assistant, or phone number. Yet when we call the number we have setup in vapi we get the above error. So strange because 'our server' n8n, never even displays the attempt let alone an error log.
I will update you tomorrow with hopefully good news that it's resolved. Thanks for your help team!
Interestingly, before we cleared the serverURL, and now that I've let it load for a little bit. We are getting the status-update into our n8n workflow webhook. But we're still not receiving the assistant request and we only receive the status update sometimes. This is a very weird issue
Alright @User Unfortunately the sporatic serverURL for assistant-request is still occuring. I called it again tonight and it worked perfectly once, then the second call only 2 minutes later didn't send the assistant request to my server, only the status-update. Please let me know what information you would like to resolve this, I'd really like to use you but this is a major issue https://cdn.discordapp.com/attachments/1419955792177528862/1423228630414393374/image.png?ex=68df8c73&is=68de3af3&hm=5f28248c8daa35716b0b0558349757904303e49213195c06271773da55f8f554&
I’d love to organise a call with your team to resolve this live if possible?
Hi @User I have further reviewed this issue extensively over the passed few days. The webhook response just gives me response 500 which is unhelpful. It confirms the path it's sending to is correct, the request isn't received on our n8n workflow at all but in postman when I send directly to the webhook it works without issue. When I "reboot VPS" in hostinger it works for the next call, but then continues to not work after the initial one worked. Please prioritise getting a fix for this as everything I find online ends in people having to migrate away from Vapi and while I really don't want to do that, we're running out of options if our agents are completely unusable.
The issue appears very similar to this thread: https://vapi.ai/community/m/1380613375356047460
To be clear, the timeout issue is also occuring but that is not a real issue as the workflow is intentionally bulky right now, we just need it reliably triggering first. Also the timeout shouldn't be the 7500ms it keeps cutting out at, we have set the timeout to 25 seconds. I've also switched to using the assistant serverURL but that didn't help either.
Good afternoon @User and @User We have resorted to completely migrating our webhook to a different host (hostinger self host to cloudflare n8n cloud hosting) to further isolate the problem which has confirmed that there is something wrong with how our self-hosted hostinger docker is setup. Could you please confirm what is required in our hosted environment to accept the assistant-request? Interestingly, the request sometimes goes through once after restarting the webhook host but never again after that until the next reboot. I have tried extensively when we were self-hosting to allow all proxy requests but still we were blocking it for some reason. While I don't have full visibility in the new host as we're not self hosting, cloudflare did send error 520 back with further error code 11200 but I believe that was because the header content-type was lost when I moved the serverURL to the phone number, this has since been resolved. I think this issue would be well suited to a live troubleshooting call if someone could please arrange a time with us. If you could please check with me that we've setup our docker n8n environment on hostinger's VPS correctly to accept assistant-requests we should be able to resolve this. Thank you, Dylan
hello? @User @User Is anyone working on this?
c
We apologize for the delay in responses lately. We are in process of making some changes to our workflow in how we handle support requests. The good news is that we are starting to get back on track of having a 48 hour response time and we would like to start cleaning up anything old. With that being said, just wanted to check in with you to see if you have made any progress or changes to your project since support has last reached out.
2 Views
PreviousNext
Powered by