> For the complete documentation index, see [llms.txt](https://docs.concurrence.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.concurrence.com/channels/sms.md). # SMS SMS channel for outbound and inbound text messaging through provisioned phone numbers. The SMS channel lets agents send and receive text messages through provisioned phone numbers. Each SMS use case has a managed sender pool, registration, consent checks, and delivery tracking. Managed infrastructure also supports MMS when the sender pool has the required capability; this does not mean every agent conversation can generate or interpret every attachment type. ## Provisioning SMS provisioning is a regulated, operator-managed process rather than a self-service Platform API or Developer Console flow. It includes the applicable carrier registration, messaging use case, and phone-number configuration. Timing depends on carrier review and number readiness. After provisioning, Concurrence supplies the use-case identifier. The Platform API binds that SMS use case to a service in the workspace. It does not create the upstream SMS setup, campaign, messaging service, or number assignment for the workspace. To request SMS provisioning for your workspace, contact your Concurrence account team. ### How Use Cases Are Backed Each provisioned SMS use case is backed by managed messaging infrastructure and an assigned phone-number pool. Sender selection occurs within that use case; callers starting an outbound conversation supply the use case and recipient, not a `From` number. ## Inbound SMS Customers can text a configured phone number to start a conversation with the agent. The platform routes the message to the bound service, resolves authorized context when available, and runs the agent's reasoning engine. Messages from the same caller on the same use case are serialized onto the current non-terminal durable conversation. Terminal Context Graph completion, closing a known conversation ID, a use-case rebind, or outbound creation with `force_new: true` starts a fresh thread; see [Phone-Keyed Threads](/channels/text-sessions.md#phone-keyed-threads). Once operator provisioning is complete, the workspace application does not configure a provider webhook for each conversation. The managed channel validates inbound delivery, deduplicates provider retries, resolves the destination use case, and records message metadata for processing and analytics. When a reply depends on supported background work, the asynchronous channel policy suppresses the intermediate acknowledgement and attempts to re-drive the final reply. Provider acceptance and delivery remain separate; inspect delivery status and recovery evidence rather than assuming the recipient received it. See [Long-Running Tools and Reply Delivery](/channels/email.md#long-running-tools-and-reply-delivery). Signature validation ensures that only authentic message deliveries are accepted. Duplicate deliveries (from network retries) are silently acknowledged without creating duplicate records. ## Outbound SMS The platform supports agent-initiated outbound SMS without waiting for an inbound text. The bound service generates the opening turn using its published configuration and the authorized context available at execution time. A recipient reply can continue the resulting durable conversation. Outbound SMS conversations are started through the conversation lifecycle API by specifying SMS as the channel, a recipient phone number in E.164 format, and a use case that determines the sender. The sender (FROM number) is resolved from the use case configuration - it is never supplied by the caller. See [Outbound](/channels/outbound.md) for details on the channel-generic lifecycle. Outbound SMS can support reminders and follow-up workflows when the workspace has a provisioned use case and the application supplies the required routing inputs. Contact the Concurrence team to confirm availability and onboarding for your workspace. {% hint style="info" %} Outbound text conversations support entity-based resolution. When an entity ID is supplied, the runtime can load authorized context available for that entity before the first message rather than relying only on phone-number matching. Missing data, source permissions, and projection lag still apply. {% endhint %} ## Channel Switching An active conversation on another channel (such as iMessage) can be switched to SMS, preserving the full conversation history. Each turn records which channel it occurred on, so the history is self-describing across channel changes. See [Outbound](/channels/outbound.md#switching-between-sms-and-imessage) for the switch lifecycle. ## Consent and Registration Carrier registration, recipient consent, and message content are separate launch requirements. The customer supplies the consent process and evidence for the intended audience and purpose; Concurrence manages the channel registration and configured send controls. A phone number in the world model is contact information, not permission to send outreach. ### Preparing a Campaign Concurrence reviews the sending business, message purpose, consent flow, sample messages, and support details before submitting the registration. The deployed workflow must match that submission, including whether messages recur and whether they contain links or phone numbers. A successful text in a demo does not establish that a production campaign is ready. The launch review establishes: * **Who is sending and why.** Identify the brand the recipient consented to hear from and the full scope of messages. Adding health coaching to a scheduling program, for example, requires reviewing whether the existing consent and registration cover the new purpose. * **Where consent is given.** Use a clearly documented SMS consent step. A recorded verbal flow can be used when its script and evidence are included in the approved campaign. A written flow should use an explicit, optional SMS choice, separate from consent to other channels. * **What the recipient is told.** Align the consent language, first message, sample messages, terms, privacy policy, sender identity, expected frequency, charges disclosure, and STOP/HELP instructions. * **How evidence is retained.** Assign responsibility for retaining the consent record and the wording presented to that recipient. For verbal consent, verify that the recording or other approved evidence actually exists and remains available. * **How customer systems stay consistent.** Agree how opt-outs reach the customer's own contact and campaign records. Concurrence's channel suppression does not automatically update every external system. Existing patient relationships, a supplied contact list, or permission collected by another organization do not by themselves establish campaign permission. A program sending on behalf of another organization needs review of that brand's consent evidence, authorization, and registration structure. Do not send an unsolicited first SMS merely to ask for consent or rely on STOP as the consent mechanism. ### The Managed Send Gate For US long-code and US/Canada toll-free sender pools, the managed channel requires a recorded opt-in message for each recipient and use case before ordinary messages can be sent. That message uses the approved registration's confirmation copy. Its record is created after the provider accepts the send; it is not proof that the recipient received it or that the customer collected valid consent. Repeating the opt-in operation does not remove an existing suppression. The same in-platform opt-in gate does not cover Canadian long-code or other international sender pools. Confirm the applicable consent and provider requirements during provisioning. The absence of this particular gate does not authorize messaging. ### Registered Content For registered US long-code and US/Canada toll-free pools, a model-based check compares an ordinary outbound text body against every registration governing the pool. Off-purpose content is blocked. If the check fails or cannot produce a usable decision, the send is blocked rather than bypassing the check. This check evaluates the text body, including the registered purpose and applicable content restrictions. It does not inspect media-only MMS content and does not establish legal compliance or clinical accuracy. Consent, suppression, and sender-capability checks still apply to those sends. ## Opt-Out and Re-Subscription An opt-out suppresses ordinary outbound SMS across the recipient's **managed business setup**, which can contain multiple use cases and sending numbers. It is broader than one conversation or campaign, but is not a universal opt-out across unrelated businesses or other channels. Agents and campaigns cannot bypass it by starting another conversation or choosing another number within that setup. | Sender path | Recognized handling | | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **US long-code with a verified campaign** | Registered opt-out keywords include `STOP`, `STOPALL`, `UNSUBSCRIBE`, `CANCEL`, `END`, and `QUIT`. Registered help keywords include `HELP`. Matching trims surrounding whitespace and ignores case. These requests are handled by the channel instead of the agent. | | **US/Canada toll-free keyword path** | `STOP` records both a line-specific opt-out and business-setup suppression. `START` or `UNSTOP` clears the line-specific record only. These keywords do not become agent turns. | The campaign keyword path attempts the registered confirmation on each recognized opt-out request and the registered help reply on a help request. Confirmation delivery can fail independently; a confirmation is not a guarantee that future messages are permitted. Do not assume the toll-free path sends the same confirmation or supports every campaign keyword. **Texting `START` does not automatically restore Concurrence delivery.** A caller with Channel Manager's `sms:consent:write` permission must separately clear the business-setup suppression after reviewing renewed consent and recording a reason. For a live toll-free opt-out, the recipient must first text `START` or `UNSTOP` to the affected line; the API cannot override that prerequisite. Opt-out history is retained after reversal. The [Channel Manager recipient APIs](https://docs.concurrence.com/developer-guide/platform-api/conversations/channel-manager#sms-recipient-opt-in-and-opt-out) let authorized clients send the registered opt-in message, read setup-wide opt-outs, and clear a suppression. These operations require separate Channel Manager consent grants; a workspace API key alone does not authorize them. ## Phone Number Assignment SMS use cases require phone numbers with SMS capability, and the registration requirement depends on the number type and country. US/Canada toll-free numbers require approved toll-free verification. US local and national long-code numbers require an approved messaging campaign. Registration makes a sender eligible for assignment; recipient consent, suppression, content checks, and provider delivery rules still apply to each message. Unlike voice channels - where a single phone number can serve different voice use cases on different channels (one for inbound voice, one for outbound voice, one for voicemail) - SMS assignment is exclusive. A phone number can only be assigned to one SMS use case at a time. This mirrors the underlying telephony constraint that a phone number belongs to exactly one messaging service. ## Channel Separation SMS and voice operate on separate channel bindings. A phone number can be assigned to both a voice use case and an SMS use case simultaneously - the two channels do not conflict. The platform tracks voice and SMS assignments independently, so assigning a number to an SMS use case does not affect any existing voice assignments on that number, and vice versa. ## Lifecycle The managed SMS lifecycle is: 1. **Provision** - A Concurrence operator creates the required channel resources and completes carrier registration. 2. **Assign numbers** - Eligible SMS-capable numbers join the use case after the applicable verification or campaign approval. 3. **Bind service** - The workspace binds the provisioned use case to an eligible service through the Platform API. 4. **Send and receive** - Messages route through the managed number pool and durable conversation path. 5. **Retire** - An operator unassigns numbers and tears down upstream resources when the use case is no longer needed. {% content-ref url="/pages/F9G0lrxZA31mW1pawkgs" %} [Text Sessions](/channels/text-sessions.md) {% endcontent-ref %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.concurrence.com/channels/sms.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.