Let Your Voice Agent Call Your Backend

The idea in one paragraph

Sometimes your agent needs to do something in your system during a call — look up an order, book a slot, charge a card. A flow function turns one of your existing HTTP endpoints into a tool the agent can use mid-conversation. You describe the endpoint once; the AI decides when to call it and fills in the details from what the caller says. No middleware, no transcript-scraping, no reacting after the call hangs up.

What you can build with it

• Look something up. Caller: "What's the status of order 12345?" The agent calls your /orders endpoint and reads the answer back in plain language.
• Book something. "I'd like a haircut Friday at 3." The agent posts the booking and confirms the slot — or offers alternatives if it's taken.
• Take an action. "Pay with the card on file." The agent triggers the charge and confirms it, or handles a decline gracefully.
• Get ahead of the caller. The agent fetches your real availability before asking about timing, so it offers actual open slots instead of guessing.

If you already have an HTTP endpoint that does the thing, you're most of the way there.

Defining a function

A flow function is a description of an HTTP request: a method, a URL, and the parameters that go into the path, query string, or body. Here's a complete one:

jsonc{
  "name": "check_order_status",
  "description": "Look up shipping status and ETA for an existing customer order.",
  "request": {
    "method": "GET",
    "url": "https://api.example.com/orders/{orderId}",
    "pathParams": {
      "type": "object",
      "properties": {
        "orderId": {
          "type": "string",
          "description": "The order number the caller referenced — digits only, no prefixes."
        }
      },
      "required": ["orderId"]
    }
  }
}

The name and descriptions do the heavy lifting. They're what the AI reads to decide when to use the function and what to fill in. Describe the function in the caller's language ("look up an order") rather than your backend's, and be explicit about formats ("digits only", "ISO 8601 date"). Clear descriptions are the difference between a function that fires reliably and one that doesn't.

Body parameters can be nested objects and arrays (up to five levels deep). Path and query parameters stay simple values, since they have to fit in a URL.

Where each value comes from

For every parameter, you choose who supplies it:

Values from the call or fixed values are filled in server-side — the AI never sees them, never has to extract them, and can't get them wrong.

There's one more useful trick. If a parameter comes from the call — say, a verified customer ID — you decide what happens when it's missing (an anonymous caller, no contact on file):

• Required → the whole function disappears from the agent's toolbox for that call. No caller identity, no refund function. You don't need prompt guardrails; the capability simply isn't there.
• Optional → the AI falls back to asking the caller, like any normal parameter.

No trigger phrases needed

You don't list magic words. The AI matches intent, so one check_order_status function fires for "What's happening with order 8842?", "Can you check on eight-eight-four-two?", and "My package — where's it at?" It cleans up spoken input too: "eight eight four two" becomes 8842 before your API ever sees it. And if the caller never mentions an order number, the agent asks for one — because you marked the parameter as required. The schema is the logic.

When your API fails

It will, occasionally — a timeout, a 500, a 404 for an order that doesn't exist. Two things keep the call alive:

• The agent keeps talking. The error goes back to the AI as the function's result, so it can say "I couldn't find that order — can you double-check the number?" instead of going silent.
• You can route failures to a recovery step. Point the function at a dedicated "order not found" node in your flow, and the caller gets a coherent recovery path instead of a dead end.

Quick answers

Does the agent wait for my API? Yes — up to a timeout you set (100 ms to 30 s, default 5 s). Callers hear a natural pause, like "let me pull that up."

Can I use my own authentication? Yes. Headers are set per function and encrypted at rest. Bearer tokens, API keys, signed requests — whatever your endpoint expects.

Can several agents share one function? Yes — define it once, reference it from any agent in any flow.

Can I transform the response before the AI reads it? Not yet — the raw response goes to the model. If your API returns something the agent shouldn't say out loud, shape the payload on your side.

Go deeper

The full reference — request shape, binding rules, validation — is at docs.talkif.ai/flow-builder/flow-functions.