How to Use OpenClaw Voice Calls

The Voice Call plugin lets OpenClaw place outbound calls, accept inbound calls, run multi-turn conversations, use full-duplex realtime voice, stream transcription, and send TTS. The docs list Twilio, Telnyx, Plivo, and a mock provider for development.

30-second answer

Install and configure the plugin on the Gateway host, restart the Gateway, run openclaw voicecall setup, then use voicecall smoke before placing real calls. At minimum, config needs provider credentials, a from number, and a public webhook URL. Choose either realtime voice or streaming transcription; do not enable both audio modes together.

Install and verify

openclaw plugins install @openclaw/voice-call
openclaw gateway restart
openclaw voicecall setup
openclaw voicecall smoke
openclaw voicecall smoke --to "+15555550123"
openclaw voicecall smoke --to "+15555550123" --yes

The setup command is meant to be readable in chat logs and terminals. It checks plugin enablement, provider credentials, webhook exposure, and that only one audio mode is active. Smoke is readiness-only by default; pass --yes when you intentionally want a real call.

Realtime versus streaming

Realtime voice selects a full-duplex realtime voice provider for live conversations. Twilio Media Streams support realtime mode, and bundled realtime voice providers include Google Gemini Live and OpenAI through their provider plugins. The realtime model can use the shared openclaw_agent_consult tool when deeper reasoning, current information, or normal OpenClaw tools are needed.

Streaming transcription selects a realtime transcription provider for live call audio. The docs list Deepgram, ElevenLabs, Mistral, OpenAI, and xAI as bundled transcription providers through provider plugins. If a configured provider is missing, Voice Call logs a warning and skips media streaming instead of failing the whole plugin.

TTS and inbound policy

Core TTS is used when Twilio media streaming is enabled; otherwise calls can fall back to provider-native voices. For inbound calls, allowlist policy is a low-assurance caller-ID screen. Webhook verification authenticates provider delivery, while allowlists decide whether a caller is allowed to interact.

CLI operations

openclaw voicecall call --to "+15555550123" --message "Hello from OpenClaw"
openclaw voicecall continue --call-id <id> --message "Any questions?"
openclaw voicecall speak --call-id <id> --message "One moment"
openclaw voicecall dtmf --call-id <id> --digits "ww123456#"
openclaw voicecall end --call-id <id>
openclaw voicecall status --call-id <id>
openclaw voicecall tail

Operator checklist

Before production, verify provider credentials, public webhook URL, signature verification, allowed hosts, proxy forwarding behavior, audio mode, TTS provider, max duration, stale call reaper timing, and logs. Never disable signature verification outside local testing.

The OpenClaw Playbook treats phone automation as high-risk infrastructure: start with notify-only calls, add one conversation path, verify logs and replay protection, then expand once customers can safely interrupt, opt out, and recover from failures.

Rollout plan

Treat How to Use OpenClaw Voice Calls as a workflow you roll out in stages, not a switch you flip once. Start with the smallest harmless proof: a status check, dry run, local-only call, private session, or read-only inspection. Confirm the documented behavior matches your installed OpenClaw version, then write the exact commands and expected output into the workspace so the next agent does not rely on memory or vibes.

For a production runbook, document credential owner, webhook or browser dependency, allowed actions, rate limits, fallback channel, and the person who can approve live external writes. Also write down what the agent may do alone, what requires approval, and what must stop immediately. That boundary is the difference between useful autonomy and a workflow that surprises the operator at the worst possible time.

Keep one rollback note beside the guide. It can be as simple as the command to disable a plugin, the channel to pause, the config key to revert, or the owner who must approve the next run. Include the proof that tells you rollback worked, and keep it visible near the production checklist for future maintainers. Agents are most useful when recovery is obvious.

After the first live run, review the transcript or logs while the details are fresh. Look for missing prerequisites, stale assumptions, broad prompts, confusing errors, and any external side effect that should have been gated. Tighten the guide, then repeat with one wider scope. The OpenClaw Playbook is built around this operating rhythm: cautious first proof, written runbook, verified automation, then gradual autonomy once the evidence is boring.