AI Chatbot Twilio SMS Integration: A Bot That Answers Real Text Messages

Why a website chatbot cannot simply be pointed at a phone number

A website chatbot lives in a browser tab. It has a session, it can render buttons and links, and nobody bills you per sentence. A text conversation has none of that. Each inbound message reaches your server as a separate HTTP request from Twilio, the only identity you get is a phone number, every reply is metered in segments, and the carriers between you and the customer run their own filtering. Reusing the website bot’s prompt and wiring over SMS produces long, chopped replies, lost context between messages and, sooner or later, filtered traffic.

What changes in practice:

• No interface. Quick-reply buttons become numbered options or plain yes-or-no questions. A carousel of products becomes one recommendation and a link.
• No session. The pairing of the customer’s number and your Twilio number is the conversation key, and your backend has to hold the history.
• Slow, asynchronous replies are normal. People answer a text an hour later. The bot has to decide whether that is the same conversation or a new one.
• Regulated sending. In the US, business texting from ordinary ten-digit numbers goes through A2P 10DLC registration, and opt-out keywords carry legal weight.

This page is about those differences. The language model is the easy part; the messaging layer around it decides whether the integration survives contact with real phones.

Choosing the sending number and getting it registered

Before a bot sends anything, the number it sends from has to be the right kind and registered for the use case. Twilio offers three common options for US traffic:

Registration asks how customers opt in, what sample messages look like, and whether messages include links or phone numbers. We write those descriptions from the actual bot design, because a campaign registered as customer care that then starts sending promotional offers is exactly what carriers audit for. If you already text customers from a Twilio number, we check its registration first; adding an AI assistant to a number registered for a narrower purpose can mean updating the campaign.

A practical question comes up early: can customers keep texting the landline printed on your vans? Twilio can sometimes text-enable a number whose voice service stays with your current phone company, through its hosted SMS process, and porting is another route. Which works depends on the number and the carrier, so we confirm it during scoping instead of promising it up front.

What happens between a customer pressing send and the bot replying

When a text arrives, Twilio sends an HTTP POST to the webhook URL configured on the number or on its Messaging Service. The request carries form-encoded fields including From, To, Body and MessageSid, plus NumMedia and MediaUrl0 onward for picture messages. Our handler works through these steps in order:

1. Verify the signature. Twilio signs each request in the X-Twilio-Signature header using your account’s auth token. The handler recomputes the signature over the exact public URL and the posted parameters and rejects anything that does not match. A classic failure: a proxy or load balancer rewrites the scheme or host, and genuine requests start failing validation. We test against the real public URL, never only on a local machine.
2. Deduplicate on MessageSid. If the same message reaches the system twice, for example once on the primary URL and again on a fallback URL after a timeout, the customer still receives a single answer.
3. Acknowledge fast. Twilio expects a quick response to its request. A model call plus a CRM lookup can take several seconds, so we return an empty TwiML response right away, generate the answer in a background job, and send it through the Messages REST API. An inline TwiML reply is fine for instant, fixed answers; the asynchronous path is safer for anything that calls a model.
4. Load the thread. Recent history for the number pair, the customer record if one exists, and a flag showing whether a staff member has taken over.
5. Generate, then check. The draft reply passes length, encoding and policy checks, described below, before it goes out.
6. Send with a status callback. Every outbound message carries a StatusCallback URL so the delivery outcome returns to the same system.

For the sending side we prefer an API key and secret created for this integration over the account’s primary auth token. A dedicated key can be revoked without breaking every other system on the account, and a subaccount can keep the bot’s traffic and logs apart from the rest of your Twilio usage. Signature checks still need the auth token, so that secret also lives only on the server.

Writing for segments: length, character encoding and links

SMS is delivered and billed in segments. A message made only of GSM-7 characters fits 160 characters in one segment and 153 per segment once it is split. A single character outside that set, such as an emoji, a curly apostrophe or an em dash, switches the whole message to UCS-2, where a segment holds 70 characters, or 67 when split. Language models produce curly quotes and dashes constantly. Left unchecked, a friendly three-sentence reply quietly becomes four segments.

The controls we put in place:

• A system prompt written for texting: one question per message, no markdown, no bullet lists, and a character budget for every answer.
• A post-processing step that swaps typographic characters for plain ones, removes stray markdown asterisks, and counts segments before sending. Messaging Services also offer a smart-encoding setting that replaces common look-alike characters; we still normalize in code so behavior does not hinge on one console toggle.
• A hard ceiling. A reply that would blow the budget gets shortened, or the bot sends a link to the full answer rather than a wall of text.
• Links on your own domain. Generic public URL shorteners are a well-known trigger for carrier filtering, so any link points at your website or at a branded short domain set up for the purpose.

Pictures flow inbound too. A customer can text a photo of a cracked part or a storm-damaged fence. The bot sees that media arrived, can pass the image to a vision-capable model where that suits the use case, and attaches it to the lead or ticket. Media is copied into your own storage under your retention rules rather than left referenced at Twilio indefinitely.

Opt-out keywords are not conversation

When a customer texts STOP, the bot must not answer with a cheerful question about why they are leaving. By default, Twilio intercepts the standard opt-out keywords, including STOP, UNSUBSCRIBE, CANCEL, END and QUIT, on long code and toll-free numbers, sends its own confirmation, and blocks further messages from that sender to that phone until the person texts START or UNSTOP. A send attempt to a blocked number returns an error instead of reaching the handset.

Our integration mirrors that state rather than fighting it:

• Opt-out messages still arrive at the webhook, so the handler records the opt-out against the contact in your CRM or database and never passes those texts to the model.
• Automated jobs such as follow-ups check the opt-out flag before queuing anything, so the system never generates blocked messages and clutters the logs with errors.
• HELP receives a fixed reply written by a person, with your business name and a way to reach staff. The model does not improvise it.
• If your account uses Twilio’s Advanced Opt-Out settings to customize keywords or confirmation text, the bot’s keyword list is aligned with them.

Consent comes before all of this. Replying to someone who texted you first is one situation; texting a number gathered somewhere else is another. Where the bot collects a number itself, for example a web chat offering to text a confirmation, it stores when and how consent was given along with the exact wording shown. Texting rules differ by message type and by state. Your attorney sets the policy and we enforce it in code, including quiet hours for any message the system starts on its own; we are engineers, not lawyers, and we do not give legal advice.

Keeping context when there is no session

SMS has no cookie, so the conversation is whatever your backend remembers. We key each thread on the customer’s number plus your Twilio number, which keeps threads separate when a business runs one number per location. A handful of rules decide what the model sees:

• Idle windows. A reply twenty minutes later continues the thread. A text three weeks later probably opens a new topic, so the bot gets a short summary of earlier exchanges instead of the full transcript.
• Known contacts. If the number matches a customer in your CRM, the bot can greet them by name and see open jobs or appointments, limited to fields you approve. A phone match alone is weak identity, since numbers get reassigned, so anything sensitive still triggers a confirming question.
• Human takeover. When staff reply on a thread, the bot goes quiet on that thread until it is handed back or goes idle. Two voices answering one customer is the quickest way to lose their trust.
• Bursts and splits. People send three short texts in a row, and long messages can arrive in pieces. The handler waits a brief moment and merges a burst from the same number before generating one reply, instead of answering each fragment.

Status callbacks and what happens when a text does not land

A successful response from the Messages API means Twilio accepted the message, not that the phone received it. Some problems are rejected at send time; the rest surface on the status callback as the message moves through states such as queued, sent, delivered, undelivered or failed, with an error code attached when something went wrong. We store the outcome per message and act on it:

Delivery receipts depend on carrier support and are not reported identically on every route, so dashboards treat a missing receipt as unknown rather than failed. The handler also watches its own dependencies: if the model provider times out, the customer gets a short holding message, staff get the thread, and nobody is left staring at silence.

How we test before a real customer’s phone buzzes

• Handler tests on recorded payloads. Plain text, multi-part bursts, MMS, STOP, HELP, a duplicate MessageSid and a request carrying a forged signature.
• Twilio test credentials for the sending path. They accept API calls without delivering or billing real messages, and Twilio’s documented magic numbers simulate invalid and non-mobile destinations.
• A staging number wired to a staging webhook and texted from our phones and yours. The scripts that matter: a brand-new lead, a returning customer, an upset customer, a question the bot must refuse, and a request for a human.
• A segment report across a set of realistic questions, so you can see how long typical answers are before launch.
• A launch watch. Through the first stretch of live traffic we review transcripts and the Twilio error logs with you and adjust prompts and guardrails based on what real customers send.

EVOTECH’s build sequence for an SMS assistant

1. A free phone or video consultation about what people text you today, which number they use, and who answers now.
2. Number and compliance review: existing Twilio account or a new one, registration status, opt-in points, and whether any texting is promotional.
3. A written quote with a fixed scope covering channels, the systems the bot reads from and writes to, handoff rules, and what is deliberately left out.
4. Build: webhook service, conversation store, prompt and guardrails, CRM or scheduling connection, staff takeover and status tracking.
5. Test and launch as described above, followed by a review of real transcripts.

Our US-based team near Houston does this work remotely for businesses across the country. If the bot also runs on your website, the SMS channel shares its knowledge base and business rules through one backend, the kind of cross-channel AI integration we build regularly. Scheduled outbound texts are a separate design, covered on our appointment reminders page, and alerts sent to staff rather than customers are covered under lead notifications.

Related services

Frequently asked questions