https://vapi.ai/ logo
Join Discord
Powered by
server url should not be required at tool level
# support
l
refer to this ticket/support : https://discord.com/channels/1211482211119796234/1262904304822653063 The fact that the server url is now required at tool level negates the ability to set a server at org/phone/assistant level as per the docs here: https://docs.vapi.ai/server-url/setting-server-urls it should be possible to set server url at ORG->Phone->Assistant->tool level The tools should not require server url, as that breaks past functionality
v
@Lucas van Staden I understand your concern regarding the requirement of the server URL at the tool level. The documentation you've referenced does indicate that the server URL can be set at various levels, including the organization, phone, assistant, and tool levels, with a specific order of precedence. The current design is intended to provide flexibility and ensure that the most specific server URL is used when making API calls. This allows for different tools to interact with different servers if necessary. However, if this change has disrupted your workflow or existing functionality, we would like to address this issue. Could you please provide more details on how this requirement is affecting your current setup? With more information, we can better understand the situation and assist you in finding a suitable solution. If this is a bug or an unintended change, we will work to resolve it promptly.
You can continue this conversation by mentioning me in the message.
l
@User It is currently used during development. I have two phone numbers setup: one for live usage, and one for development/testing features. The end point url is setup to each number : one fo rlive, one for test server example: https://api.vapi.ai/phone-number/ba1ca873-xxxx-xxxx-xxxx-xxxx was used to setup url endpoint to a specific server on each number { "serverUrl": "https://xxxxxx.ngrok-free.app" } For development, so I can test API endpoint changes, the one phone endpoint is setup via ngrok to my local dev system. This then allows me to enact the exact same AI as live, use the same tool functions, but, due to calling the 'dev' number, the api calls is to my local dev instance. This way I can test new code on api endpoints This is possible due to the documented server url level of priority, and that server url was never required on tool level. Now, because all tools require a server, there is no way to push quires to a different domain/server, and the only way forward is to duplicate each tool, and set the duplicated to allow the dev testing. By making the tools require urls, the current documentation is also invalid, as there is then no point to have the ability to set endpoints / urls on ORG/Phone/Assistant level, as they will ALWAYS be overridden by the tools. IMO, it seems to be you need to FLIP the priority levels, and make TOOLS the lowest priority, thus allowing to keep them required, and populated, and then allow assistant/phone/org to override the base tool set URL. I hope that clarifies. In the same way we will be using phone based urls to divert different businesses to different servers closer to their geographical locations, but still use the same AI/tools, without having to duplicate everything The change you made seems more limiting than benificail IMO I am open to changin the workflow, if there is a way to acheive the setup I noted above
a further issue now, due to the fact one cannot remove the url set in the tool URL, is that the live quesries will divert to dev, and the only way to fix this is to delete the tool, and create it again. The tool url requirement seems quite problematic and very scope limiting to me
c
This is not true - Maybe you have a misunderstanding. 1. You are doing things in the dashboard that is ery limited. The setting of url's throughout the account work perfectly fine and don't limit us in any way. https://docs.vapi.ai/api-reference/tools/create-tool
How is a tool going to trigger if it has no URL (webhook) to send information for the automation you are building? If you build the same tool over multiple times how would the tool work if there was only one server url?
l
It is not setyting teh url that is the issue, is the fact the tools urls are now required. This then negates the ability to use the prior set urls at ORG/phone and assistant level. Since the tool URL is always preferred over the previous set URL's then there is no point in having the ability to set the main domain/server url at the other levels, as tools will always override those. So why have them then even?
c
It does not. That only applies to tools. Tools need a serer url or they cant trigger.
Just like functions did. It is the eaxct same.
l
> How is a tool going to trigger if it has no URL (webhook) to send information for the automation you are building? By using the server url, set at phone level, as decribed in docs. SERVER URL can be set at org/assistant/phone level. > If you build the same tool over multiple times how would the tool work if there was only one server url? The endpoint api can be dynamic, and detect the TOOL function name, and be dynamic. example: topol payload: "function": { "name": "createBooking", "arguments": { "from": "2024-10-20T09:00:00", "notes": "AI created", "patientId": "1444839390529464121", "businessId": "1412116764182980070", "practitionerId": "1435963156395468556", "appointmentTypeId": "1449946899393029368" } } code that handles it $type = request()->body()['message']['type']; switch ($type) { case "tool-calls": handle_request(); break; case 'assistant-request': .... function handle_request() { foreach (request()->body()['message']['toolCalls'] as $callData) { $function = $callData['function']['name']; $id = $callData['id']; Leaf\Config::set([ 'log.file' => $callData['id'] . '_' . $function . '.log', 'log.dir' => __DIR__ . '/logs/' . request()->body()['message']['call']['customer']['number'] . '/' ]); app()->logger()->info(request()->body()); if (function_exists($function)) { $function(); } else { response()->status(404); exit; } } } so the one sngle api endpoint can handle any tool's functionality by being dynamic.
Thsi ha sbeen woking for over a year, and now, making tool urls required, and negating the baility to set teh SDERVER_URL at the previous scopes breaks things and limits the baility to make things dynamic
As per docs, if the server_url is NOT set at TOOL level, the SERVER URL will be used a per pecedance. https://docs.vapi.ai/server-url/setting-server-urls it is a documented feature. It literally says: ....to handle call events.
what is the point of having the ability to set server url at the other prior levels (so making them GLOBAL over all tools) if tools now override them. If this i teh case, the docs need to be updated.
c
Yes - so put a different url - Een when functions were here that was not trigger a function a function call. (url from your org). You always had to set a different url.
l
It literally says you can set server urls at ORG/PHONE/ASSISANT level: 'to handle call events'
you did not read my reasonong, did you?
and I can use ONE endpoint to handle ALL api calls.
c
Your right, my bad I don't know what I am talking about. @Sahil @Shubham Bajaj can you help.
l
and I can divert the AI to a diffrent server depending on client location, be that USA, AU etc by setting the endpoint GLOBALLY depending on their geo data / phone number format / dialling country code etc. as an example. upon making an assistant-request to the GLOBAL api endpoint (a base server setup in vapi against organisation) the caller PHONE can be detected, and their claling country ID can be parsed from that
Copy code
"call": {
            "id": "-----",
            "orgId": "--------",
            "createdAt": "2024-09-11T09:35:20.286Z",
            "updatedAt": "2024-09-11T09:35:20.286Z",
            "type": "inboundPhoneCall",
            "status": "ringing",
            "phoneCallProvider": "twilio",
            "phoneCallProviderId": "------",
            "phoneCallTransport": "pstn",
            "phoneNumberId": "-----",
            "assistantId": null,
            "squadId": null,
            "customer": {
                "number": "+6149999999"
            }
        },
Then in tha ssistant request one can divert all tool cals to another server, geo located closer to the inbound call, $assistant['serverUrl'] = 'https://webhooks.server.com.au' or if it was a USA phoen number $assistant['serverUrl'] = 'https://webhooks.server.com' and all tools will divert from then on to a server geographically located closer to them. This is to allow the API endponts, which also communicate with various other API's to get faster results as they will be geographically closer to the vapi tool end point servers. This can shave literally 5/6 seconds off api endpoint times to result back.
now, because the TOOLS overriding the GLOBAL scoped server urls, one cannot be as dynamic as before. In my current setup, I use the server urls to divert the calls to a dev server to I can test and not intefere with client, and I can also divert the server endpoints to servers located in their countries, via the assistant request api call detecting their geo location. This is now also no longer a possibility https://cdn.discordapp.com/attachments/1297202823049646130/1297327364304535664/image.png?ex=671585c2&is=67143442&hm=f424bbecf5d6ad98f88cb8c03004977b79d2f8a90591a901526a161affbc2174&
My main gripe is that doing the required setup of the tool urls, negates the documented server url setups, and makes them pointless, and basically limits the dynamic nature of how things can be done.
it limits vapi more than it benifits IMO
> You always had to set a different url. Not true. function calls would (and have been) using the prior set SERVER_URL values. Only people who cannot make their own dynamic API endpoints (so using make etc) will benefit form this adjustment, as they need to have a different url on each tool. Tools end point urls should not be required if the tool is custom, and not using no-code endpoints like make.com etc.
c
I was referring to that as well - but I don;t know what I am talking about. The team will comment and help soon.
l
i hope so, as this is a serious issue, as 6 months of work has been done, and things were planned as per current document ability to use server urls dynamic on assistant-requests and also how the dev flow works. All work has now been stopped, as if this is a change that will stay, we either need to abandone vapi, or completely change everything. Vapi has basiclaly limited it's own dunamic ability with this change.
we will nee to clone ai's and change every tools end point depending on geo location and have a lot of duplication on ai's just so each can use a set of (identical) tools to use a different geo located server
c
I dont think so as this is the first time I seen a ticket like this - and many other people code as well. Even so you can still use functions - just not on new Assistants. Duplicate your old ones and change the url.
l
we need teh urls' to be able to be set dynamic on assistant-request api request. this is no longer possible. it is a big change.
the change breaks previously documented ability to use globally set end-points via global set server-url values at org/phone/assistant level. For easy of use, we have ben using teh vapi dashboard to edit/.set tools. I will be looking at moving that to using API calls. i gather the required 'nature' of teh url is a vapi dashboard issue alone....i hope.
c
So to clarify you were only using the dashboard and not the API's for your clients during all of the time you were building?
l
we set the ai base functionality via vapi dashboard, pull that in on assistant call, then adjust dynamically (by exampel setting server url), and result the adjust assistant to the request result
c
So no..or you only used two endpoint. "Get and Update Assistant"?
l
get.
c
Ohh I see now why you think that. Def check the full api docs.
l
we don;t use update assistant. The assitant BASE is done in VAPI, then we get that, adjust via code, and result that back to the vapi call request.
so, if, the requirement that the url is required is ONLY a vapi dashboard issue, I can bypass that using APi calls to set the tools and the AI BASE details
so, at least this is not as huge a issue as initially thought, just a massive annoiance
initially this was thought to be a total structural change, but seems it may only be dahsboard. your question there did spark that 'ahhh moment' 😉
did not even think of that, due to panic of wtf ae we going to do if thsi is how it must now work....
c
I was just curious how you were doing all of that without using any other endpoints. Also this change did not just happen either - so your stiff would hae broke a long time ago. Also the way you are doing it, lets just say is "a lot". You could just use create call and make an assistant on the fly. You dont need the dashboard to push back or get anything from.
If its the assistant is really the same you dont change the JSOn.
l
> Also this change did not just happen either - so your stiff would hae broke a long time ago I needed to add a new param to all tools yesterday, and discovered that the dashboard would not save, then found the post referred to stating that tool urls are now required. The tools work 100% without configured server-urls, falling back to the noted phone or assistant set server-url. I should have noted that and realised it is teh dashboard only that now limits and requires a value, not the actual backend vapi system. >Also the way you are doing it, lets just say is "a lot". You could just use create call and make an assistant on the fly. You dont need the dashboard to push back or get anything from. I am not pushing the assistant back, I am pulling the dashboard created assistant (so call it my base assistant), which holds the base prompt and tools configured via the 'easy to use' dashboard. The assistant-requst api call then adds in data to the prompt (client data, name, next appointment), and then results back the assistant data (so in effect creating assistant on the fly, but using the dashboard base, since it was easy to setup the base) so I first pull into the assitant-request the assistant $assistant = $vapi->getAssistant($_ENV['assistant_id']); $assistantCustom = [ 'voice' => $_ENV['assistant_voice_id'], 'name' => $_ENV['assistant_name'], ]; // get the base prompt as setup inside vapi which contain base details $prompt = $assistant['model']->messages[0]->content; In vapi dashboard I use placeholders for certain data $prompt = str_replace('{APPOINTMENT TYPES}', ... ), $prompt); Since the dashboard exists, and is easy to use, why recreate that again for own usage. at no point am I pushing back and updating the base assistant via the api call. Using the dashboard to setup the tools, and setup teh base prompt with all the clinik data was just easy.
> I was just curious how you were doing all of that without using any other endpoints. You don't need a separate endpoint to every tool. It all depends on the server code getting the request. So, using PHP, I can make the calls dynamic, since every tool passes along it's name. Request payload:
Copy code
"message": {
        "type": "tool-calls",
        "toolCalls": [
            {
                "id": "call_kzqrDE43sJq5SGtFFRmfnVLU",
                "type": "function",
                "function": {
                    "name": "createPatient",
                    "arguments": {
                        "name" : "koos",
                        "surname" : "kombuis",
                        "email" : "koos@gmail.com",
                        "dateOfBirth": "1972-12-27"
                    }
                }
            }
        ],
        "toolCallList": [
....
then on the server there is no need to setup any routing, or multiple endpoints etc. One index.php file can handle all the requests by dynamically calling a function in the script (or a class instantiated) - this is really fast, and don't require a lot of setup on the server side. a really basic PHP server, like PHP's own internal server, can handle the request. Don;t need apache/nginx or anything else more complex. Is really fast. on server, using leaf/PHP one can quickly build out an api to handle every tool call
Copy code
$app->post('/', function () use ($app) {
    $is_genuine = isset(request()->body()['message']['type']); // replace later with some security confirm for keywords.
    if (!$is_genuine) {
        response()->status(401)->plain('Signature verification failed!');
    }
    $type = request()->body()['message']['type'];
    switch ($type) {
        case "tool-calls":
            handle_request();
            break;

        case 'assistant-request':
            $clientName = '';
            $functions = new Functions();
            $cliniko = $functions->getCliniko();
            $vapi = new Vapi();
            $now = gmdate("Y-m-d H:i:s", time());
            $assistant = $vapi->getAssistant($_ENV['assistant_id']);
            $assistantCustom = [
                'voice' => $_ENV['assistant_voice_id'],
                'name' => $_ENV['assistant_name'],
            ];
....
Copy code
function handle_request()
{
    foreach (request()->body()['message']['toolCalls'] as $callData) {
        $function = $callData['function']['name'];
        $id = $callData['id'];
        Leaf\Config::set([
            'log.file' => $callData['id'] . '_' . $function . '.log',
            'log.dir' => __DIR__ . '/logs/' . request()->body()['message']['call']['customer']['number'] . '/'
        ]);
        app()->logger()->info(request()->body());
        if (function_exists($function)) {
            $function();
        } else {
            response()->status(404);
            exit;
        }
    }
}
so there is a PHP function that matches the tool name exact, and the dynamic call of $function() uses the tool name to effect the call to the function so, you don't need to have a separate end-point for every tool. The tools can use the globally configured server-url as what can be set on ORG/Phone/Assistant This way I can also divert all tool calls to different servers (which is what will be done) as the api endpoints they call are located around the world, and it speeds up the tool results significantly. The clinical database that is accessed uses sharding to separate data dependant on clinic location. so, if the API server for tools is hosted in Australia, and the client clinic is in USA, the delay for api calls from AU->USA ads abount 2/3s delay.
Hope that clarifies why I am doing it as I am.
so, I can assign server-urls to phone numbers, depending on the location of that clinic, or I can assign server-url to assistant, base don the callers phone data (picking up on the country code of the claler phone)
It is all about the 3rd party api's and delays in fetching client data. It really speeds things up quite a bit.
This change just now means I will need to change how the base assistant and tools are managed, and not use the vapi dashboard anymore. The underlying server-url usage as documented still works. That was my misunderstanding, not realising it was a dashboard only change
so, i am going to close the ticket. I still think making the server url required is wrong, but this is a UI choice, not an operational change on how tools work.
s
just checking in @Chowderr and @Lucas van Staden is it resolved?
2 Views
PreviousNext
Powered by