diff --git a/fern/assistants/dynamic-variables.mdx b/fern/assistants/dynamic-variables.mdx index 4b38a4a24..5846351cc 100644 --- a/fern/assistants/dynamic-variables.mdx +++ b/fern/assistants/dynamic-variables.mdx @@ -69,18 +69,27 @@ For example, set the assistant's first message to "Hello, `{{name}}`!" and assig These variables are automatically filled based on the current (UTC) time, so you don't need to set them manually in `variableValues`: -| Variable | Description | Example | -| ----------------------- | --------------------------------- | ------------------------- | -| `{{now}}` | Current date and time (UTC) | Jan 1, 2024 12:00 PM | -| `{{date}}` | Current date (UTC) | Jan 1, 2024 | -| `{{time}}` | Current time (UTC) | 12:00 PM | -| `{{month}}` | Current month (UTC) | January | -| `{{day}}` | Current day of month (UTC) | 1 | -| `{{year}}` | Current year (UTC) | 2024 | -| `{{customer.number}}` | Customer's phone number | +1xxxxxxxxxx | -| `{{customer.X}}` | Any other customer property | | -| `{{transport.conversationType}}` | Whether the conversation is over `chat` or `voice` | `chat` | -| `{{transport.X}}` | Any other transport-related property | | +| Variable | Description | Example | +| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------ | +| `{{now}}` | Current date and time (UTC). For other timezones, use the LiquidJS `date` filter -- see [Advanced date and time usage](#advanced-date-and-time-usage) below. | Jan 1, 2024 12:00 PM | +| `{{date}}` | Current date (UTC) | Jan 1, 2024 | +| `{{time}}` | Current time (UTC) | 12:00 PM | +| `{{month}}` | Current month (UTC) | January | +| `{{day}}` | Current day of month (UTC) | 1 | +| `{{year}}` | Current year (UTC) | 2024 | +| `{{customer.number}}` | The customer's phone number (caller-ID for inbound calls, destination for outbound calls). | +1xxxxxxxxxx | +| `{{customer.X}}` | Any other customer property you set when creating the call. | | +| `{{phoneNumber.number}}` | The Vapi phone number that received the inbound call or placed the outbound call. | +1xxxxxxxxxx | +| `{{phoneNumber.name}}` | The display name you set on this phone number in the dashboard. | `Main Support Line` | +| `{{call.id}}` | The unique Vapi-generated ID for this call. Useful for correlating with your own logs, support tickets, or webhooks. | `5fe26c8e-...` | +| `{{call.type}}` | The kind of call this is. Useful for branching prompt behavior between channels. | `inboundPhoneCall` / `outboundPhoneCall` / `webCall` | +| `{{transport.callSid}}` | The provider-side call session ID (e.g. Twilio's `CallSid`). Useful for BYOT customers correlating with their own provider logs. | `CA1234...` | +| `{{transport.conversationType}}` | Whether the conversation is over `chat` or `voice`. | `chat` | +| `{{transport.X}}` | Any other transport-related property. | | + + +To pass these values **between tool calls within an assistant** (rather than templating them into prompts), see [Static variables and aliases](/tools/static-variables-and-aliases). That page documents the trust tiers for these variables -- which are signaling-derived and safe to use as a security boundary in tool calls, vs. conversation-derived ones that are not -- and shows how to inject them into tool calls deterministically, without LLM mediation. + ## Advanced date and time usage diff --git a/fern/tools/custom-tools.mdx b/fern/tools/custom-tools.mdx index daeba7095..7b1b818d7 100644 --- a/fern/tools/custom-tools.mdx +++ b/fern/tools/custom-tools.mdx @@ -119,6 +119,20 @@ vapi listen --forward-to localhost:3000/tools/webhook `vapi listen` is a local forwarder that requires a separate tunneling service. Configure your tool's server URL to use the tunnel's public URL for testing. [Learn more →](/cli/webhook) +## Other tool types that accept custom function parameters + +Custom function tools are not the only tool type where you can define an LLM-facing JSON schema. Several other tool types accept the same `function.parameters` customization, so the dashboard's **Parameters** editor (or the `function` field in the API) works the same way across them. + +| Tool type | Customer-defined `function.parameters`? | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `function` (custom) | Yes — the entire purpose of this tool type. | +| `apiRequest` | Yes — drives both the LLM-supplied arguments and the request body construction. | +| `code` | Yes — the parameters become inputs to your TypeScript code. | +| `handoff` | Yes — fills handoff-time arguments inline. See [Approach 1 in the squads guide](/squads/passing-data-between-assistants#approach-1-handoff-arguments). | +| `transferCall`, `endCall`, `dtmf`, `voicemail`, `sms`, `slack-send-message`, GHL/Google integrations, `mcp`, `make`, Anthropic-native (`bash`, `computer`, `textEditor`) | No — the schema is Vapi-controlled or auto-derived from the underlying integration; you do not define it directly. | + +For tool types that accept customer-defined `function.parameters`, you can also pair them with **static parameters** -- a separate top-level `parameters` array on the tool that merges server-trusted values into the body without the LLM ever seeing them. See [Static variables and aliases](/tools/static-variables-and-aliases) for the full pattern, including when to use static parameters as a security boundary. + ## Alternative: API Configuration For advanced users who prefer programmatic control, you can also create and manage tools via the Vapi API: