Flow Functions
Let the LLM call your backend mid-conversation with a structured HTTP request shape — path, query, and body parameters, each with their own JSON Schema.
Flow functions give your agents a way to reach live data during a call: look up an order, check availability, create a ticket, verify a customer — anything where the conversation needs to talk to your systems.
The shape
Each function defines method, URL, and three independent parameter locations:
| Location | Supports | Use |
|---|---|---|
pathParams |
primitives | /orders/{orderId} style placeholders |
queryParams |
primitives | ?source=phone&limit=10 |
body |
nested objects and arrays (depth 5) | JSON request body |
Parameter names are unique across all three locations, URL placeholders must match pathParams keys, and the dispatcher percent-encodes path values to prevent injection.
Where values come from
Each parameter is bound to one of three sources:
llm— the model extracts the value from the conversationcall_context— server injects from the active call (caller identity, variables). Never shown to the LLM.onNull: rejecthides the function for that call;fallback_to_llmexposes it.static— fixed value baked in. Never shown to the LLM.
This lets you keep sensitive identifiers server-side while still giving the LLM everything it needs to decide when and how to call the function.
Execution
Functions run server-side. Headers are encrypted at rest with AES-256-GCM. Timeouts are configurable (100–30000ms, default 5000). If the function has transitionTo, the agent transitions even when the HTTP call fails — the LLM sees the error in the new node's context.
See the flow functions docs for the full request shape, binding modes, and validation rules.