Authentication node (Pro)

An Authentication node checks a caller’s identity against an Auth Directory before letting the conversation continue — the way you’d gate a “check my balance” or “cancel my order” step behind a PIN.

What it does

Placed on a node in the conversation graph, an Authentication node:

Asks the caller to identify themselves (by phone number, or by a caller ID already known from the call) and enter their PIN.
Looks the identity up in a chosen Auth Directory and checks the PIN.
On a match, lets the call continue down a success branch and remembers, for the rest of the call, that this caller passed this check.
On a mismatch, gives the caller another attempt (up to a configured limit) and, once attempts run out, continues down a failure branch instead. An optional cancelled branch is taken if the caller backs out of the check instead of finishing it.

Directories are the only method, for now

Today an Authentication node can only check a caller against an Auth Directory — a per-project list of identities, each with a phone number and a PIN, managed from the project’s Authentication tab. Other verification methods appear in the node’s underlying design but aren’t offered in the editor yet; directory checking is the one production path.

Voice, keypad, or both

Each Authentication node has an input method setting with three options:

Keypad (DTMF) — the caller enters their PIN using their phone’s keypad. This is the most reliable option, since it doesn’t depend on speech recognition getting digits right.
Voice — the caller speaks their PIN and the agent transcribes it.
Both — the node accepts whichever comes first, keypad or voice, and ignores the other. This is a good default: callers on a phone that supports keypad tones get the more reliable path, while callers who can’t or won’t use the keypad (a web/text session, for example) can still speak the PIN.

Because a web or text session has no phone-keypad concept, keypad entry only applies to phone calls; on other channels the node falls back to a typed or spoken value.

What it stores for later steps

On a successful check, the node can save the caller’s verified identity into a variable you choose (the node’s output variable). The saved value carries the directory entry’s id, display name, and phone number, so later nodes in the flow — a greeting, a lookup, anything downstream — can reference it, for example a Say node reading Welcome back, {my_variable.name}. Leaving the output variable unset simply skips this step; nothing is written.

Set the number of PIN attempts allowed (default three) before the check counts as failed. If the caller abandons the check partway through, the node’s optional cancelled branch takes over instead of counting it as a failure.

Guarded steps (“critical sections”)

Any other node in the flow can be marked protected by a specific Authentication node. Once protected, that node can only ever be reached after a caller has cleared that Authentication node’s check earlier in the same call — if the flow somehow routes a caller to a protected node before they’ve passed the check, they’re sent to the Authentication node instead, so the protected step never runs unauthenticated. This is how you guarantee that, say, an account-cancellation step can only be reached by someone who has proven who they are, no matter how the flow branches to get there.

The protect this node control appears on every node’s edit form, but only once the flow contains at least one Authentication node to protect it — pick which Authentication node guards this step, or leave it unset for no protection. A flow can use more than one Authentication node (for example, a lighter check earlier and a stricter one guarding a more sensitive step later); each protected node names exactly which check it depends on.