Where automation meets judgment.
Switchboard is the control plane between your automated workflows and the phone calls they place to real people.
Switchboard is the control plane between your automated workflows and the phone calls they place to real people.
Hold the token, move the call in time, cap what it costs.
CALL-E issues a one-time confirm token. Switchboard keeps it out of your workflow and releases it only when a person says so.
A scheduled call is not prepared until it falls due, so nothing has been sent and cancelling it genuinely cancels. CALL-E ships no cancel tool.
Per-campaign call caps, checked again at dial time. A runaway loop stops at the cap instead of at your invoice.
CALL-E built a confirm token. Workflow hosts pass it straight through.
Placing a call is irreversible. CALL-E's own tooling flags it as destructive, and issues a one-time token to gate it. But in a workflow that token travels from one step to the next in milliseconds, so no person is ever involved. Switchboard takes custody of it.
Drop it into a workflow and the calls stop being automatic.
The node plans the call and stops. Your workflow gets a job id and a flag, never the token. Await Result blocks until a person decides, then dials and polls to completion.
Not built yet. The policy, scheduling and budget logic is a plain Node module with no n8n dependency, so porting it is mostly adapter work.
Every one of these came out of a live run against the API, and every one of them is why a Switchboard feature exists.
The MCP surface is plan_call, run_call, get_call_run and track_ui_events. Once a run is submitted, nothing stops it.
So Switchboard holds scheduled jobs itself and never hands CALL-E a future time.result.extracted always returns the same six keys. CALL-E does the extraction you ask for, then flattens it into prose.
So we validate what came back and report the gap instead of claiming structured output.next_step.action can be ask_user_for_missing_info. In a headless workflow that request is simply swallowed.
So the console is the inbox for it, with the question rendered and an answer box.calle regions list returns a documentation URL. There is no programmatic way to know whether a number is callable.
So our list is a dated snapshot you can override, and it says so when it blocks you.Questions about Switchboard, CALL-E and running it yourself.
A control plane for CALL-E phone calls. It plans a call, keeps the confirm token, and refuses to spend it until a person approves. It also batches, schedules, enforces policy and caps spend per campaign.
No. Dry run mode builds and displays the exact command that would be sent without contacting CALL-E at all. CALL-E also publishes a US test hotline, so you can run the whole loop end to end without involving a real person.
No. Use @call-e/n8n-nodes-calle to place calls. Switchboard decides
whether they happen. It is a custody layer, not a calling node.
Before it dials, the token is discarded and no call is ever placed. After
run_call has been sent, Switchboard stops tracking the job but the call
may still happen. CALL-E ships no cancel tool, so nothing can recall it.
In a local JSON file, deliberately inspectable. It is never emitted into workflow
data, and it is destroyed the moment it is spent. Your pipeline sees
hasConfirmToken: true, never the value.
No, and it is not meant to. A human gate costs latency, and by the hundredth call someone will approve without reading. CALL-E targets low-frequency personalised phone tasks. At ten calls a day a gate is affordable. At ten thousand, use auto mode with tight policy limits instead.
Open source, no dependencies, and free to evaluate without spending a single call.