> Fetch clean Markdown by appending `.md` to any page URL under https://signalwire.com/docs or requesting it with the HTTP header `Accept: text/markdown`. The root index at https://signalwire.com/docs/llms.txt lists the available documentation indexes.

# Glossary

> One canonical definition per SignalWire term, with the aliases and historical names each one answers to.

[addresses]: /docs/platform/addresses

[agent-base]: /docs/server-sdks/guides/agent-base

[ai-method]: /docs/swml/reference/calling/ai

[ai-overview]: /docs/platform/ai

[api-credentials]: /docs/platform/your-signalwire-api-space

[authorization]: /docs/apis/authorization

[base-url]: /docs/apis/base-url

[browser-sdk]: /docs/browser-sdk/v4/guides/overview

[cfb-ai-node]: /docs/call-flow-builder/reference/ai-agent

[cfb]: /docs/call-flow-builder

[chat-token]: /docs/apis/rest/chat-tokens/create-chat-token

[compat-rest]: /docs/compatibility-api/rest

[cxml]: /docs/compatibility-api/cxml

[expressions]: /docs/swml/reference/expressions

[relay-client]: /docs/server-sdks/guides/relay-client

[projects-api]: /docs/apis/rest/projects/create-subproject

[resources]: /docs/platform/resources

[sat]: /docs/browser-sdk/v4/guides/authentication

[segment-ids]: /docs/platform/what-is-a-sid

[server-sdks]: /docs/server-sdks

[signup]: /docs/platform/signing-up-for-a-space

[subscribers]: /docs/platform/subscribers

[swaig]: /docs/swml/guides/swaig

[swml-calling]: /docs/swml/reference/calling

[swml-messaging]: /docs/swml/reference/messaging

[tool-calling]: /docs/platform/ai/tool-calling

[video-token]: /docs/apis/rest/video/room-tokens/create-room-token

[webhooks]: /docs/platform/webhooks

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.

One account owns two Spaces, `example.signalwire.com` and `example-dev.signalwire.com`. The first Space holds two Projects, one of which holds a Subproject; the second Space holds one Project.

### Space \[#space]

The subdomain created alongside your SignalWire account, in the form `example.signalwire.com`. Your [Dashboard][signup] 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][base-url] for API requests. It appears alongside your Project ID and API tokens under **API Credentials** in the Dashboard.

### Project \[#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](#subproject), one level deep.

#### Subproject \[#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][projects-api]. Note that Subprojects must release their phone numbers before they can be deleted.

#### Project ID \[#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][api-credentials].

In the Compatibility API, this is called the **Account SID** for compatibility with other providers.

### API token \[#api-token]

A Project-scoped credential used server-side, and the password half of HTTP Basic [authentication][authorization]. 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 \[#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:

| Token name                                      | Description                                                              |
| ----------------------------------------------- | ------------------------------------------------------------------------ |
| [API token](#api-token)                         | Server-side, per Project. The password half of Basic authentication.     |
| [Subscriber token (SAT)](#subscriber-token)     | Short-lived, per Subscriber. Bearer credential for the Browser SDK.      |
| [Embed token][sat]                              | Lives in a public page, tied to one resource, for click-to-call widgets. |
| [Video Room token][video-token]                 | Client-side credential for Video, created with an API token.             |
| [Chat token][chat-token]                        | Client-side credential for Chat, created with an API token.              |
| [Personal access token](#personal-access-token) | Per user, not per Project. Downloads FreeSWITCH binaries.                |

## Call Fabric \[#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][resources] reachable at an address, so one dialing model reaches all of them and all of them are managed the same way.

### Resource \[#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][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 \[#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 \[#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 \[#subscriber]

A [Resource][subscribers] 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 \[#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][sat] 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 \[#relay-application]

A Resource type representing your own server connected over [Relay](#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 \[#call-flow]

A Resource type holding a call flow built visually in [Call Flow Builder](#call-flow-builder). Like any Resource, it has an address and can be dialed.

## Calls

### Call \[#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](#call-leg), and it can pass through several Resources on the way.

#### Call leg \[#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).

### Segment ID \[#segment-id]

A UUID identifying one [leg](#call-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][segment-ids] shows where to find them in the Dashboard.

## SWML

### SWML document \[#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][swml-calling], the document type for voice calls, and JavaScript expressions in `${...}` are a Calling SWML feature. A second document type, [Messaging SWML](#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 \[#messaging-swml]

The [document type][swml-messaging] 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][expressions].

### SWAIG \[#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](#swaig-function) an agent invokes. See the [SWAIG guide][swaig] and the [tool calling guide][tool-calling].

#### SWAIG function \[#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][tool-calling].

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 \[#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](#swml-document) and SignalWire executes it. See the [webhooks guide][webhooks].

## Interfaces

### Server SDKs \[#server-sdks]

The unified server-side SDK, published as `signalwire-sdk` on PyPI and `@signalwire/sdk` on npm. It exposes three namespaces — [Agents](#agents-namespace), [Relay](#relay), and [REST](#rest-namespace) — and you can use one or combine all three in a single application. See the [Server SDKs documentation][server-sdks].

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](#browser-sdk), which is a different package for client-side code.

#### Agents namespace \[#agents-namespace]

The namespace that builds AI-driven call flows declaratively. Your agent runs an HTTP server; SignalWire requests a [SWML document](#swml-document) from it and manages speech recognition, the model, and tool calling for the rest of the conversation. `AgentBase` is its [base class][agent-base].

#### Relay namespace \[#relay]

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][relay-client].

Reach for Relay when you need to react to a call as it unfolds. Reach for [SWML](#swml-document) 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](#relay-application), which is the Dashboard Resource that routes a call to your Relay client.

#### REST namespace \[#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 \[#browser-sdk]

The client-side SDK for voice, video, and chat in the browser, published as `@signalwire/js`. It authenticates with a [subscriber token](#subscriber-token), never with an API token. See the [Browser SDK documentation][browser-sdk].

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 \[#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][compat-rest]. Its markup language is [cXML](#cxml).

The Compatibility API is not the route to SignalWire AI. Use [SWML](#swml-document) or the [Server SDKs](#server-sdks) for that.

#### cXML \[#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][cxml].

**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](#resource) — and on Dashboard labels such as **cXML/LaML**. When you see LaML in a name or a URL, read cXML.

### Call Flow Builder \[#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][cfb]. What it produces is a [Call Flow](#call-flow) Resource.

## AI agent \[#ai-agent]

"AI agent" names five different things across SignalWire products. The product you are reading about tells you which one is meant:

| Where you read it                | What "AI agent" means there                                                                                   |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------- |
| [SWML][ai-method]                | The `ai` method: runs a conversation on a live call, joining speech recognition, a model, and text-to-speech. |
| [The platform][ai-overview]      | SignalWire AI as a capability: prompts, contexts, state, and tools.                                           |
| [The Dashboard][resources]       | The AI Agent Resource type: configured in the Dashboard, reachable at an address like any Resource.           |
| [Server SDKs][agent-base]        | An `AgentBase` application: your Python or TypeScript program that generates SWML at request time.            |
| [Call Flow Builder][cfb-ai-node] | The AI Agent node: one block in a visual call flow.                                                           |

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.