Calling SWML overview
Calling SWML is the flavor of SWML used to handle voice calls — inbound calls arriving on a phone number configured with a SWML calling handler, outbound REST-initiated calls that point at a SWML URL, and re-fetches triggered by methods that hit an external URL.
For handling inbound SMS and MMS messages, see the Messaging SWML overview.
Document structure
A Calling SWML document follows the standard
SWML document structure — a top-level sections map with
sections.main as the entry point. Each section contains an array of calling methods
that run sequentially.
Webhook and variable payload
When SignalWire fetches a Calling SWML document from an external URL, it POSTs this payload to
your server — on the initial inbound fetch and on every fetch triggered by a method that hits
an external URL (execute with a remote URL,
transfer,
enter_queue.wait_url, and
connect.confirm). Your server must respond
with a valid SWML document using one of these content types: application/json,
application/yaml, or text/x-yaml.
Inside the executing document, the call, params, and envs fields are available for
variable expansion via ${...} (JavaScript expressions) and %{...} (path substitution). As
the script runs, methods also populate the vars.* runtime scope — those values are not in
the initial inbound payload, but they are propagated across transfer boundaries and delivered
on subsequent fetches.
call
Information about the current call. Call-specific and read-only. Each call leg has its own
call object with its own call_id, from, and to. A document that runs on the leg
connect dialed sees that leg’s values. SignalWire clears call.peer when the bridge ends,
so the document that resumes after connect doesn’t have it. See
Call legs.
call.address_id
ID of the Resource Address the call was placed to. Present on calls a Subscriber places to an Address.
call.call_id
A unique identifier for the call.
call.call_state
The current state of the call.
call.dial_winner
Set to "true" when this call is the leg that answered an outbound dial, including the
winning leg of a parallel dial. Omitted otherwise.
call.direction
The direction of this call. Possible values: inbound, outbound.
call.from
The number/URI that initiated this call.
call.from_number
The phone number that initiated this call. Present for phone calls (type is phone); SIP
and WebRTC calls expose the originator through from instead.
call.headers
The headers associated with this call. Present for phone and SIP calls, as an empty array when there are none. WebRTC calls don’t include it.
call.headers[].name
The name of the header.
call.headers[].value
The value of the header.
call.node_id
A unique identifier for the node handling the call.
call.parent
The call that created this call. Present only when this call has a parent, for example a
leg created by a connect.
call.parent.call_id
A unique identifier for the parent call.
call.parent.device_type
The device type of the parent call: phone, sip, or webrtc. Present only when this
call was created by a connect, from either the SWML connect method or the Relay
connect command; omitted for any other parent call.
call.parent.node_id
The same value as this call’s own node_id, not the parent call’s node.
call.peer
The call this call is bridged to. Present only when this call has a peer.
call.peer.call_id
A unique identifier for the peer call.
call.peer.node_id
The same value as this call’s own node_id, not the peer call’s node.
call.project_id
The Project ID this call belongs to.
call.segment_id
A unique identifier for the current call segment.
call.space_id
The Space ID this call belongs to.
call.subscriber_id
ID of the Subscriber who placed the call. Present on calls a Subscriber places from the Browser SDK.
call.subscriber_name
Name of the Subscriber who placed the call: their display name, or if that’s empty their
first name, then their email, then Subscriber. Present on calls a Subscriber places to an
Address.
call.tag
The tag you assigned to this call when it was created, if any.
call.to
The number/URI of the destination of this call.
call.to_number
The destination phone number of this call. Present for phone calls (type is phone); SIP
and WebRTC calls expose the destination through to instead.
call.type
The type of call. Possible values: sip, phone, webrtc.
call.sip_data
SIP-specific data for SIP calls. Only present when call.type is sip. Each key is
included only when the call’s SIP signaling carries a value for it, so a key missing from one
call can be present on another.
call.sip_data.sip_contact_host
The host portion of the SIP Contact header.
call.sip_data.sip_contact_params
The URI parameters of the SIP Contact header, as key/value pairs. Present only when that URI carries parameters. Each value is a string. A parameter without a value is left out, so the object can be empty.
call.sip_data.sip_contact_port
The port from the SIP Contact header.
call.sip_data.sip_contact_uri
The full URI from the SIP Contact header.
call.sip_data.sip_contact_user
The user portion of the SIP Contact header.
call.sip_data.sip_from_host
The host portion of the SIP From header.
call.sip_data.sip_from_params
The URI parameters of the SIP From header, as key/value pairs. Present only when that URI carries parameters. Each value is a string. A parameter without a value is left out, so the object can be empty.
call.sip_data.sip_from_uri
The full URI from the SIP From header.
call.sip_data.sip_from_user
The user portion of the SIP From header.
call.sip_data.sip_p_asserted_identity
The P-Asserted-Identity header of the incoming SIP request. Only the first P-Asserted-Identity header is read, and only when its URI has a user part.
call.sip_data.sip_req_host
The host portion of the SIP request URI.
call.sip_data.sip_req_params
The URI parameters of the SIP request URI, as key/value pairs. Present only when that URI carries parameters. Each value is a string. A parameter without a value is left out, so the object can be empty.
call.sip_data.sip_req_uri
The full SIP request URI.
call.sip_data.sip_req_user
The user portion of the SIP request URI.
call.sip_data.sip_to_host
The host portion of the SIP To header.
call.sip_data.sip_to_params
The URI parameters of the SIP To header, as key/value pairs. Present only when that URI carries parameters. Each value is a string. A parameter without a value is left out, so the object can be empty.
call.sip_data.sip_to_uri
The full URI from the SIP To header.
call.sip_data.sip_to_user
The user portion of the SIP To header.
params
vars
Runtime variable scope, populated by methods as the script executes. Not part of the
initial inbound payload — values appear here only after a method that sets them has run.
The full vars object is propagated across transfer boundaries (and on remote-URL
execute) and delivered as a top-level vars field on subsequent webhook payloads.
Created by: set — explicitly create or update
variables. Method outputs — many methods auto-populate variables (e.g., prompt_value,
record_url, return_value). See each method’s reference page for what it sets.
Removed by: unset.
Scope: One call leg. Variables persist across all sections, through execute calls, and
through transfer to a new document. They don’t cross to another leg: a document that runs on
the leg connect dialed starts with an empty vars, and the leg that issued connect keeps
every variable. See Call legs.
Access: Variables can be accessed with or without the vars. prefix. When you reference
a variable without a scope prefix (e.g., ${my_variable}), SWML first checks vars. If not
found in vars, it automatically falls back to envs.
envs
Environment variables configured at the account or project level. Account/project-scoped and read-only. Set in your SignalWire account configuration, not within SWML scripts.
Fallback behavior: When you reference a variable without a scope prefix (e.g.,
${my_variable}), SWML first checks vars. If not found in vars, it automatically falls
back to envs.
The envs object is included in POST request bodies to external servers, but the ability
to set environment variables in the SignalWire Dashboard is not yet available in
production. This feature is coming soon.
See Variables for variable-expansion syntax, deployment-mode differences, and tips on accessing nested fields and array elements.
Methods
A method is a single step in a SWML document — each item in a sections.<name> array invokes
one method. Each method’s reference page documents its parameters, defaults, and any output
variables it sets. Methods below are grouped by what they do.
Conversational AI
Hand the call to an AI agent that holds a natural conversation, recognizes intent, and can call out to your backend via SWAIG functions or webhooks.
Call lifecycle
Control when the call is answered, ended, and what kind of party is on the other end before deciding how to handle it.
Audio & speech
Play audio to the caller, prompt for input, and stream live transcription or translation. Run background transcription of the call, and reduce noise for clearer audio.
Connecting parties
Bring other phones, SIP endpoints, video rooms, or queued agents into the call.
Recording & taps
Record the call to storage, or stream call media to an external sink in real time.
Messaging & side channels
Send messages, faxes, DTMF, and other out-of-band signals from inside a call. Also collects payments and emits custom project events.
Control flow
Direct execution within a SWML document — call subroutines, jump between labels, branch on expressions, or tail-call into another document entirely.
State & integration
Manage script variables, pause execution, and reach your backend over HTTP.