> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ouraicalling.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Node reference
> Every node type in the flow builder, with its fields and behavior
## Start
Entry point of every flow. Defines the **greeting** and the **greeting mode**:
* `agent speaks first` — the greeting is spoken as soon as the call connects (typical inbound).
* `user speaks first` — the assistant waits for the caller (typical outbound: the callee says "Hello?" first).
## Agent
A conversational agent with its own **name**, **instructions**, and optional **voice override**. The conversation stays with this agent until it hands off along one of its outgoing edges.
* Each outgoing edge becomes a **handoff tool**; the edge label is the tool description the LLM uses to decide. See [why labels matter](/flow-builder/overview#why-edge-and-agent-labels-matter).
* Empty instructions use the assistant's system prompt (Advanced prompt) as the base; node text is **appended**, not replaced.
* Voice override lets different agents speak with different voices.
## Condition
A forced decision point. You write a **description** of what is being decided; the LLM must choose exactly one outgoing edge based on the edge labels. Use it when routing must happen *now*, rather than whenever the agent feels like handing off.
## Tool
Runs a centrally managed **API or built-in tool** mid-conversation and feeds the result back to the LLM. The node stores only the selected Tool Library reference plus flow-local bindings and transitions. Endpoint, credentials, description, and reusable behavior are edited under **Tools**.
| Field | Purpose |
| ----------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| `name` / `description` | How the LLM understands what the tool does |
| `url`, `method`, `headers` | The HTTP request (GET/POST/PUT/PATCH/DELETE) |
| `params_schema` | JSON Schema of parameters the LLM should extract from the conversation |
| `timeout_ms` | Request timeout |
| `speak_during` | Announcement spoken when the tool starts |
| `async` | `true` → conversation continues while the tool runs; result arrives as a follow-up |
| `filler_phrases`, `filler_delay_sec`, `filler_interval_sec` | Rotating phrases spoken during long waits |
For long-running webhooks (CRM writes, availability checks), set `async` and add two or three filler phrases. The caller keeps a fluent conversation while the request completes in the background.
## Transfer (blind)
Immediately transfers the call to a **phone number or SIP URI** (SIP REFER), optionally after a short **announcement**. The assistant leaves the call; there is no briefing of the receiving person.
## Warm transfer
The premium handover: the caller is put on **hold music**, the assistant dials the target (an employee), **briefs them with an AI-generated summary** of the conversation so far, and only then connects both parties. The employee can accept or decline; voicemail at the target is detected.
| Field | Purpose |
| ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `number` | Target (E.164 or `sip:` URI) |
| `announcement_to_caller` | What the caller hears before being put on hold |
| `briefing_instructions` | Extra instructions appended to the automatic summary briefing |
| `ringing_timeout_sec` | How long to ring the target (5–120 s, default 30) |
| `hold_music` | Hold music while briefing the supervisor (`true`/`false`, or a catalog track id from the Warm Transfer tool) |
| `fallback` | What happens if the target doesn't answer / declines: `continue` the conversation, `end` the call, or `cold_transfer` (blind transfer to the same number) |
Warm transfer outcomes (`started` / `completed` / `failed`) are recorded as call events.
## Collect
Structured data capture with **built-in validation, re-asking, and confirmation** — far more reliable than hoping the LLM transcribes an email address correctly.
* **Types:** `name`, `email`, `phone`, `address`, `date of birth`, `dtmf` (digits via keypad), `credit_card` (payment card).
* **Variable** (required): the result is stored under this name and included in the `call.completed` webhook.
* **Prompt**: optional extra instructions on top of the built-in dialogue.
* **Max attempts** (default 3): after final failure, the flow takes the edge labeled `failed` if present.
* **DTMF digits**: for type `dtmf`, how many digits to collect.
* **Payment card** (`credit_card`): requires a **Collect payment card** built-in tool assigned to the assistant (plan-gated), with a connected Stripe account selected. During the call the agent collects card details securely; the platform creates a Stripe Payment Method on that account. Only `card_last4` / `card_brand` / `stripe_payment_method_id` are stored — never PAN/CVV. Connect Stripe under Tools → App Store first. Use the Payment Method ID later to charge via Stripe.
## DTMF
Prompts the caller to enter a fixed number of **digits on the phone keypad** (30 s timeout). Use `collect` with type `dtmf` when you want validation and retries; use this simpler node for quick menu choices.
## End
Terminates the call, optionally speaking a **farewell** first. Always give your flows explicit endings — it produces clean call statuses and prevents the conversation from drifting after its job is done.
## Central Tool Library
**Add node** opens a searchable Tool Library. New nodes store a stable `user_tool_id`; reusable configuration is never copied into the flow:
| Registry tool | Flow placement |
| --------------- | ----------------------------------------------------------------------- |
| API | Generic **Tool** node |
| Call transfer | Dedicated **Transfer** node |
| Warm transfer | Dedicated **Warm transfer** node |
| DTMF input | Dedicated **DTMF** node |
| Collect keypad | Dedicated **Collect** node |
| Other built-ins | Generic referenced **Tool** node |
| MCP server | Assistant-wide assignment only; it is not one deterministic flow action |
Use **Edit in Tools** to change reusable settings. The change applies to every assistant and flow that references the tool, including active calls at the next safe invocation boundary.
Tool, transfer, warm-transfer, DTMF, and collect-keypad nodes always select a central tool from the Tools page. The editor does not create or edit inline tool configurations. An unresolved, inactive, or incompatible reference follows the node's safe failure path and records `flow_tool_ref_unresolved`.