Answer call

Picks up the incoming call. Drop this near the start of any flow that needs to talk to or hear the caller — without it, the call stays in pre-answer state…

What it does

Picks up the incoming call so the rest of the flow can talk to and hear the caller. Until a call is answered it sits in a pre-answer state where the carrier silently rejects most voice commands — speaking, recording, gathering digits, and starting playback all need an answered leg. Putting Answer call at (or very near) the start of an inbound flow is the way to unlock everything else.

The node sends an answer_call command to Telnyx and then waits for the carrier's call.answered event before advancing — the next step runs only once the carrier confirms the leg is up. There's one important shortcut: if the flow was bootstrapped from an extension-to-flow originate (the user already picked up the originated leg before the flow entered), the worker skips the answer command entirely and advances via on['call.answered'] immediately. Telnyx rejects answer_call on an outbound leg that's already up, so this branch keeps those flows from stalling.

When to use it

• As the first non-trigger node of any inbound flow that plays prompts, gathers digits, or records the caller
• Right before a say greeting so the caller hears it as soon as the line connects
• Inside a sub-flow whose first node needs to confirm the leg is live before doing voice work (defensive, but harmless)
• Before a record voicemail capture — recording on a pre-answer leg is a silent no-op

Configuration

The node has no configuration fields — it just answers.

Picks up the incoming call. Drop this near the start of any flow that needs to talk to or hear the caller — without it, the call stays in pre-answer state and most voice steps will be silently rejected by the carrier.

This node has no configurable fields.

Outgoing events: call.answered

Examples

Standard inbound greeting

Answer the call, then immediately read a greeting and route to the menu.

{
  "id": "answer",
  "type": "answer",
  "config": {},
  "on": { "call.answered": "greeting", "call.hangup": "end" }
}

The flow waits on call.answered. When the carrier confirms the leg is up, the next node (greeting) runs.

Gotchas

• Answering twice is harmful. A second Answer call on a leg that's already up is rejected by Telnyx (call already in non-bridged state). Don't loop back through it — and remember sub-flows usually inherit an answered parent leg, so they don't need their own answer.
• Outbound-leg shortcut is silent. When the worker sees state.alreadyAnswered, it skips the answer command and synthesizes the transition. There's no call.answered webhook in that path, so don't attach side-effect logic that depends on the webhook firing — branch on the next node instead.
• Pre-answer voice steps fail quietly. Putting say, playAudio, or gatherDigits before answer doesn't error — the carrier just drops the command and the flow stalls waiting for an event that never fires. If a flow seems stuck on its first prompt, check that it's been answered.
• No call.answered edge means stuck. This node has no auto-advance fallback. If on['call.answered'] is missing or points at a non-existent node, the flow sits forever (until the caller hangs up). Always wire the edge.