Glossary
This glossary defines each SignalWire term, with the aliases and historical names it answers to and the similar terms it should not be confused with. An alias is listed only where it is still live in the product, such as a Dashboard label, an API path or field, an SDK parameter, or a package name, and each entry says where.
Accounts and access
One account owns one or more Spaces, each Space holds one or more Projects, and a Project can hold subprojects.
Space
The subdomain created alongside your SignalWire account, in the form example.signalwire.com. Your Dashboard lives there, and every API request goes through it over HTTPS. One account can own and access multiple Spaces, and each Space can hold many Projects.
Its hostname is also your Space URL, the base URL for API requests. It appears alongside your Project ID and API tokens under API Credentials in the Dashboard.
Project
A grouping of resources inside a Space, according to any classification you choose, such as by customer, or by region. Each Project has its own Project ID and API tokens, so a Project is the unit of both organization and access. A Project can hold subprojects, one level deep.
Subproject
A Project nested one level beneath a root Project. A Subproject is a full Project with its own Project ID and Resources, but Subprojects cannot contain other Subprojects.
Subprojects can be created and deleted through the Projects API with a Project’s API token; creating or deleting a root Project through the API takes a Personal access token. A Project must release its phone numbers and remove its Subprojects before it can be deleted, and the last Project in a Space cannot be deleted.
Project ID
The UUID that identifies a Project to the API, and the username half of HTTP Basic authentication. Find it under API Credentials in the Dashboard.
In the Compatibility API, this is called the Account SID for compatibility with other providers.
API token
A Project-scoped credential used server-side, and the password half of HTTP Basic authentication. A Project can hold several tokens, each with its own scopes, and you create and revoke them from the Dashboard or through the REST API.
An API token does not belong in a browser; client-side credentials are created by calling an API endpoint with it.
Personal access token
A user-level Dashboard token, issued from the user menu rather than from a Project’s API Credentials page. It authenticates you as a person rather than a Project: it is prefixed pat_, has no scopes, and carries your owner or admin role in the Space. It is the credential for the Space Administration API, and on the Projects and Project Tokens APIs it unlocks what a Project’s API token can’t do, such as creating or deleting a root Project. It also authorizes you to download FreeSWITCH and FreeSWITCH Advantage binaries. It is not interchangeable with an API token; see Authorization for how to send one.
The tokens at a glance:
Resources and Addresses
SignalWire’s addressing model. Every communication entity — a user, a script, an AI agent, a SIP endpoint, a video room — is a Resource reachable at an Address, so one dialing model reaches all of them and all of them are managed the same way. The Dashboard and the /api/fabric/ REST paths still use the name Call Fabric for this model.
Resource
A container object representing one communication entity. Every Resource has a Type and one or more Addresses that make it reachable. The REST API defines fourteen types and reports each Resource’s in the type field of its response: Subscriber, AI Agent, SWML Script, SWML Webhook, cXML Script, cXML Application, cXML Webhook, Call Flow, Relay Application, FreeSWITCH Connector, SIP Credential, whose type value is sip_endpoint, SIP Gateway, Dialogflow Agent, and Video Room. The Dashboard also offers Remote AI Agent, which has no REST API type. All types share the same addressing and management model.
Capital-R Resource is not the generic “REST resource” of an API path. The REST namespace of the Server SDKs uses “resource” in that looser sense too.
Resource Address
The path that reaches a Resource, in the form /context/name. Every Project starts with a public and a private context, and you can add named contexts of either access type from the Dashboard. The name defaults to the Resource’s name in lowercase. An AI agent named Sigmond in the public context is reachable at /public/sigmond.
Addresses are mutable and a Resource can have several, including phone numbers and SIP URIs. When you’re addressing a Resource from within its own context, you can omit the context: a Subscriber named Bob in the private context is reachable at /private/bob, or, from within that context, just /bob.
The REST API reference calls it a Fabric Address.
Phone number
A number in E.164 format on your Space. As an Address type it maps to a Resource, which is how an inbound call to that number reaches your script, agent, or Subscriber.
Subscriber
A Resource type representing a user in your communication system, with authentication, communication endpoints, and billing attached. The Browser SDK calls the signed-in Subscriber a User in code (client.user); the Dashboard, the platform docs, and the REST API all say Subscriber.
Subscriber token
A short-lived credential identifying one Subscriber and carrying the capabilities granted to them, sent as Bearer authentication. Also written Subscriber Access Token or SAT. Your backend creates one using your Project’s API token and hands it to the browser, where the Browser SDK uses it to open a session.
Three variants exist for different levels of trust: the default SAT for a signed-in Subscriber, a Guest SAT that your backend creates for a visitor and limits to a list of Addresses, and an Invite SAT that a signed-in Subscriber creates for one recipient and one Address. A separate Embed token serves public widgets.
Relay Application
A Resource type representing your own server connected over Relay. It carries a topic, and calls addressed to the Resource are sent to whichever connected Relay client is subscribed to that topic. The Dashboard labels the field Topic. In the Server SDKs, RelayClient subscribes to it through its contexts parameter.
A Relay Application is not the Relay namespace of the Server SDKs and not the Server SDKs themselves. It is the Dashboard-side Resource that routes a call to code you are already running.
Call Flow
A Resource type holding a call flow built visually in Call Flow Builder. Like any Resource, it has an Address and can be dialed.
Video Room
A Resource type holding a room that several participants join at once, by audio or video, so an inbound call lands in a shared conversation instead of a one-to-one leg. A WhatsApp caller joins by audio only. Also written Conference Room in the REST API reference and the Dashboard Address picker; the Dashboard’s Resource list and the platform docs say Video Room.
Calls
Call
The whole call as the person on the other end experiences it, from the moment it is placed on the platform to the moment it ends. It is the umbrella term: one call is made of one or more legs, and it can pass through several Resources on the way.
Call leg
The relationship between two user agents. A call is made of one or more legs: forwarding an inbound call to a single SIP endpoint is two legs, and fanning it out to four endpoints is five.
In SWML each leg has its own call object with its own Call ID, and connecting to a new leg re-initializes that object with the new leg’s data.
Call ID
The UUID of one leg, fixed from the moment the leg starts until it hangs up. In Calling SWML it is call.call_id. In the Relay namespace of the Server SDKs it is call.id. SWML status callbacks and AI webhooks send it as call_id. Connecting to a new leg gives that leg its own Call ID, which the first leg’s webhooks report as peer.call_id.
Segment ID
The UUID of a leg’s log record, and the identifier to quote in a support ticket. A leg’s first segment reuses its Call ID, so for an ordinary call the two are the same value. If SignalWire re-routes the leg to a new handler, such as a SIP REFER or a cXML transfer, a new segment begins on the same leg: the Segment ID changes and the Call ID does not. Messages and faxes have Segment IDs too.
The Dashboard labels it Segment ID in every log’s detail view, and the Segment IDs page shows where. The REST APIs return it as id, and Calling SWML exposes it as call.segment_id. The Compatibility API writes it SID, as in CallSid, and its Dashboard log pages use the same abbreviation.
The identifiers at a glance:
The conversation_id in AI webhooks is the value you set in ai.params, not a platform identifier.
SWML
SWML document
A document written in SignalWire Markup Language, in YAML or JSON, that tells SignalWire how to handle a call or a message. It has a top-level sections map with sections.main as the entry point, and each section holds an ordered array of methods that run in sequence.
Unqualified, “SWML” means Calling SWML, the document type for voice calls, and JavaScript expressions in ${...} are a Calling SWML feature. A second document type, Messaging SWML, shares the document structure and nothing else: different method sets, different webhook payloads, different variable rules, and separate error code namespaces.
Messaging SWML
The document type for inbound SMS and MMS. A document can run up to 100 method steps and 10 request calls per inbound message, and execution stops at either ceiling.
Messaging SWML is not Calling SWML with a smaller method set. It supports only plain variable substitution with %{path.to.value} — no JavaScript, no method calls, no operators. For dynamic behavior, use switch to branch and request to fetch computed values from your server. See the expressions reference.
SWAIG
The SignalWire AI Gateway: a JSON protocol over HTTP by which an AI agent calls code you host. SignalWire POSTs a JSON object to your endpoint and your endpoint returns one. SWAIG is how tool calling works on SignalWire — it is the transport behind every SWAIG function an agent invokes. See the SWAIG guide and the tool calling guide.
SWAIG function
A named capability you hand to the agent — a name, a description, and a JSON Schema describing its parameters. Each call is one HTTP POST answered by one JSON reply, with nothing held open in between. See the tool calling guide.
A SWAIG function is not an ordinary webhook, in four ways. The model decides when to call it, reading your description, rather than an event triggering it. The reply’s response field is written into the agent’s conversational context rather than spoken verbatim. A function declared via SWAIG.includes adds a discovery step — a function signature request — that enumerates available functions when the agent loads; a function declared inline needs no such request, since its signature is already in the document. And a data_map variant runs on SignalWire’s side, so it needs no webhook endpoint of yours, though it can still fetch from HTTP APIs you name.
Webhook
An HTTP request SignalWire sends to your server when an event occurs, such as an inbound call or message. Some webhooks also let your response direct what happens next: you reply with a SWML document and SignalWire executes it. See the webhooks guide.
Interfaces
Server SDKs
The unified server-side SDK, published as signalwire-sdk on PyPI and @signalwire/sdk on npm. It exposes three namespaces — Agents, Relay, and REST — and you can use one or combine all three in a single application. See the Server SDKs documentation.
It was previously offered as two products, the Agents SDK and the Server SDK; links to either name now land on the unified Server SDKs documentation.
The Server SDKs are not the Browser SDK, which is a different package for client-side code.
Agents namespace
The namespace that builds AI-driven call flows declaratively. Your agent runs an HTTP server; SignalWire requests a SWML document from it and manages speech recognition, the model, and tool calling for the rest of the conversation. AgentBase is its base class.
Relay namespace
SignalWire’s real-time protocol for imperative call control — JSON-RPC 2.0 over a persistent WebSocket — and the SDK namespace that speaks it. Your code subscribes to topics, reacts to events as they arrive, and issues commands: answer, play, collect digits, record, bridge, transfer. See the Relay client guide.
Reach for Relay when you need to react to a call as it unfolds. Reach for SWML when you can describe the whole flow up front.
The persistent, authenticated WebSocket connection a RelayClient holds is its Relay session: over one session it subscribes to topics, receives events, and carries every call and message it handles.
Realtime SDK and Relay Realtime SDK are the names of the Node.js package @signalwire/realtime-api, the earlier Relay client for JavaScript. Relay in either name means this namespace.
Relay is not a Relay Application, which is the Dashboard Resource that routes a call to your Relay client.
REST namespace
The synchronous HTTP client for the platform APIs: purchasing numbers, provisioning Resources, querying logs. Request and response, with no connection held open.
Browser SDK
The client-side SDK for voice, video, and chat in the browser, published as @signalwire/js. It authenticates with a subscriber token, never with an API token. See the Browser SDK documentation.
Version 2 was branded the Relay SDK for JavaScript; that name is historical and unrelated to the Relay namespace of the Server SDKs.
Compatibility API
The REST API that mirrors Twilio’s* request and response shapes so existing code written against Twilio runs against SignalWire with minimal change. See the Compatibility API documentation. Its markup language is cXML.
The Compatibility API is not the route to SignalWire AI. Use SWML or the Server SDKs for that.
cXML
Compatibility XML, the XML language for controlling calls, messages, and faxes through the Compatibility API. It is compatible with Twilio’s TwiML, so existing TwiML documents work without modification. See the cXML specification.
LaML is the former name of cXML and of the Compatibility API. It is retired as a product name but still live as an identifier, so you will keep meeting it: in /api/laml/ URL paths, in the RestClient.LaML SDK namespace, in the LAML Bins resource of the Compatibility API — not a Resource — and on Dashboard labels such as cXML/LaML. When you see LaML in a name or a URL, read cXML.
Call Flow Builder
The no-code visual tool in the Dashboard for building voice applications as a tree of nodes. See the Call Flow Builder documentation. What it produces is a Call Flow Resource.
AI agent
“AI agent” names five different things across SignalWire products. The product you are reading about tells you which one is meant:
Lowercase “AI agent” is the general idea. The capitalized AI Agent names the Resource type and the node.
*Twilio and TwiML are trademarks of Twilio, Inc. SignalWire, Inc. and its products are not affiliated with or endorsed by Twilio, Inc.