I'm using an apiRequest tool (GET) that calls my API to look up a customer by phone number. The URL is: https://my-app.com/api/v1/customers?filter[phone_number]={{customer.number}} The problem is {{customer.number}} returns something like +12025551234, but the + gets decoded as a space in the query string, so my API receives 12025551234 instead of +12025551234. I've also tried: - Passing it in parameters with { key: "filter[phone_number]", value: "{{customer.number}}" } — doesn't arrive in params on GET requests - Passing it in body with value: "{{customer.number}}" — the dynamic variable doesn't resolve (sends empty string) - Using {{ customer.number | url_encode }} in the URL — Vapi rejects it as invalid URL Is there a way to URL-encode dynamic variables in apiRequest tool URLs, or pass them as query params that work with GET requests?

Based on the documentation, dynamic variables can be inserted into URLs using double curly braces, and LiquidJS syntax is supported for dynamic adaptation. However, there is no explicit support or example for URL encoding (such as

url_encode

) in the URL field for apiRequest tools, and using

{{ customer.number | url_encode }}

is not currently accepted as a valid URL. Suggestion: For now, ensure that the value of

{{customer.number}}

is already URL-encoded before passing it to the assistant, so the

+

character is preserved as

%2B

in the query string.

json
"https://my-app.com/api/v1/customers?filter[phone_number]=%2B12025551234"

If you control the variable input, pre-encode it before sending. If not, consider reaching out to Vapi support for feature enhancement regarding URL encoding in dynamic variables. For more details, see the [Vapi documentation on dynamic variables and apiRequest tools](https://docs.vapi.ai/tools/default-tools). Source: - [Default Tools | Vapi Documentation](https://docs.vapi.ai/tools/default-tools)

This looks like classic query encoding behavior—+ gets treated as a space unless it’s explicitly encoded as %2B, and Vapi’s URL templating doesn’t reliably handle inline filters like url_encode. A practical workaround is to normalize the number before the request (e.g. store/send it without +, or encode it server-side via a proxy endpoint that accepts raw input). Alternatively, switching to POST with query parsing on your backend tends to be more reliable with dynamic vars in Vapi. I can help you set this up cleanly—are you able to introduce a small proxy endpoint or are you constrained to hitting that API directly? @KillUa

We're looking into this and will get back to you soon.