OpenClaw over SMS

SMS is the plainest channel OpenClaw has: an official plugin, installed separately, that receives and sends SMS and MMS through a Twilio phone number or Messaging Service. The Gateway registers a webhook route, validates Twilio’s request signatures by default, replies through the Messages API and records delivery callbacks; it is direct messages only. The setup is short. The part people miss is that everything can be configured correctly and US carriers can still deliver nothing, because of a registration that has nothing to do with OpenClaw. Here is what you need, the setup, the webhook rule, and that registration.

What you need

• The plugin, installed from its package; a Twilio account with an SMS-capable number, MMS-capable if you want attachments, or a Messaging Service; the Account SID and Auth Token.
• A public HTTPS URL that reaches the Gateway, because Twilio delivers messages by calling it.
• A sender policy: pairing by default for private use, an allowlist of preapproved numbers, or open only for intentionally public access.
• One Twilio number can serve both SMS and voice calls if it has both capabilities; the two webhooks are configured separately and use separate Gateway paths.

This is separate from OpenClaw channel setup: webhook signature validation, pairing, and outbound credentials can all be correct while carriers still block or filter delivery.

The setup

Install the plugin, choose the sender in Twilio and save the SID, the token and the number or the Messaging Service SID. Write the channel config, enabled, the credentials, the from-number, the public webhook URL and the DM policy, and apply it with a config patch after a dry run. In the number’s messaging settings, point the incoming-message webhook at the Gateway’s SMS path with the POST method; the path can be changed in config. Then expose exactly that path to the public URL: the same route serves inbound webhooks and the short-lived, tokenized attachments OpenClaw hands out when it sends MMS, and the docs show a Tailscale funnel scoped to that one path for local testing.

The US registration

• SMS and MMS sent by an application from a US local number to US recipients require A2P 10DLC registration; toll-free numbers and short codes have their own verification. Trial accounts cannot register.
• Before relying on such a sender, confirm in Twilio that a compliance profile is approved, that the brand and campaign are registered, that the number is registered and in the sender pool of the approved service, that the campaign describes the real use case with matching sample messages, and that every opt-in path is documented with public evidence.
• Consent has to be voluntary and separate from service terms or purchase, with the disclosures Twilio requires, proof of consent retained, standard opt-out keywords honoured, and one confirmation after an opt-out; the docs list the three rejection codes and what each means.

A phone number for OpenClaw voice calls is the voice side of the same Twilio number, and OpenClaw on WhatsApp the channel most people pick when SMS registration is more than they want.

The public path

The webhook is the one place SMS needs the Gateway reachable from outside, and the docs scope it to the single path rather than the whole port. OpenClaw and Tailscale explains the funnel that does that, and the security page covers webhook exposure and sender controls.

On Diali

SMS is one of the connectable channels on Diali: the Twilio account, the number and the registration stay yours, the plugin, the webhook path and the Gateway are ours. SMS on Diali is the channel page and Hosted OpenClaw on Diali the assistant.

• Twilio number or Messaging Service, one webhook path, pairing by default.
• Expose the path, not the port.
• US delivery needs A2P 10DLC, and that is Twilio’s gate, not OpenClaw’s.