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.
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.
Unlike Projects, Subprojects can be created and deleted through the Projects API. Note that Subprojects must release their phone numbers before they can 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.
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, and its use is FreeSWITCH-specific: it is what authorizes you to download FreeSWITCH and FreeSWITCH Advantage binaries. It is not interchangeable with an API token.
The tokens at a glance:
Call Fabric
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.
Resource
A container object representing one communication entity. Every Resource has a Type — Subscriber, SWML Script, cXML Script, AI Agent, Call Flow, Relay Application, FreeSWITCH Connector, SIP, Conference Room — and one or more addresses that make it reachable. 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. The context is public or private, and the name defaults to the Resource’s name. 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.
Some older pages say “Fabric address”; it names the same thing.
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, a Guest SAT, and an Invite SAT — alongside a separate Embed token for public widgets.
Relay Application
A Resource type representing your own server connected over Relay. It carries a context, and calls addressed to the Resource are handed to whichever Relay client is subscribed to that context.
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.
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. A leg’s call_id is the same identifier the logs show as its Segment ID.
Segment ID
A UUID identifying one leg of a call — or one message or fax — in the logs, written SID. A call with several legs produces several segments, and each leg keeps its SID for its whole lifecycle. In Calling SWML, the same identifier appears as the leg’s call_id.
The REST APIs return it as id, and it is the identifier to quote when filing a support ticket. The Segment IDs page shows where to find them in the Dashboard.
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 per inbound message, and execution stops at that 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 entirely on SignalWire’s side, with no server of yours involved at all.
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 contexts, 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 contexts, receives events, and carries every call and message it handles.
You’ll also see the all-caps spelling RELAY on older pages, along with the names Realtime SDK and Relay Realtime SDK. All three refer to this namespace; the capitalization carries no meaning.
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 Call Fabric 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.