Integrations. Twilio
Twilio integration that sends from your system and logs every reply on the customer record.
Most companies that text customers run it off a cell phone at the front desk, or a texting app nobody else can see into. The appointment lives in the scheduling system. The reminder goes out from somewhere else, and the reply lands on a phone that goes home at five. None of it reaches the customer record, so two people ask the same customer the same question, and the no-show that one reply would have prevented happens anyway.
We wire Twilio into the system where the work already gets recorded, so reminders, dispatch updates and two-way conversations go out from it and land back on it. Text first. Voice and WhatsApp where the operation needs them. Your CRM or operations system stays the record of the customer, and Twilio is just the wire. Registration, opt-out handling and delivery tracking are in the build from the first day, because in messaging that's the difference between texts that arrive and texts that quietly don't.
What we connect
What gets connected between Twilio and your other systems?
The flows below are the ones we build most often. The scope for your integration names exactly which of them apply, in which direction, and which system wins when the two disagree.
- Appointment and service reminders fire off the schedule you already keep, and the delivery status gets written back onto the appointment. The office can see which reminders arrived and which customers need a phone call.
- Dispatch and job status texts go out when a job gets assigned, a tech is on the way, or the work is done. Status changes in your operations system drive them, so nobody has to remember.
- Two-way texting logged on the customer record, with each reply routed to whoever should answer it. The conversation is one thread in one place. No screenshots forwarded around the office.
- Opt-in and opt-out status lives on the customer record and gets checked before every send from every system, so a STOP honored in one place is honored everywhere, including by automations somebody adds later.
- Missed-call text-back and call logging where voice matters. A customer who called and got no answer gets a text back, and the call still shows on their record.
- WhatsApp for the customers who live on it, running on the same account and writing to the same record. Business-initiated conversations need approved message templates, and those get written and submitted as part of the build.
- Delivery reporting into your system, with undelivered messages flagged by reason. When a number gets filtered or a list goes stale, you see it on the report.
How it works
How does a Twilio integration work?
Twilio has a REST API that sends SMS and WhatsApp messages and places calls, and it reports back through webhooks. Every message we send names a callback URL. Twilio posts delivery updates there as the message moves from queued to sent to delivered, or to undelivered with a reason attached. Inbound works the same way. A customer replies, Twilio posts that reply to the integration, and the integration writes it onto the right record and pings the right person. Twilio signs its webhook requests, and we verify the signature before trusting any of it.
Every send is keyed to the record and the event that triggered it, so a retry after a timeout can't text a customer twice about the same appointment. The opt-out check runs in that same path, against the customer record, before every message from every trigger. Outbound throughput on a US number is capped and tied to your registration. Batches queue and drain at the allowed rate, failed sends retry with backoff, and anything still failing lands in a queue with its reason attached.
A delivery report runs on a schedule and shows what went out, what landed, and what came back undelivered, grouped by reason. A falling delivery rate is how carrier filtering announces itself. A separate monitor watches the pipes and raises a person when callbacks go quiet or the queue stops draining. All of it gets built first against Twilio's test credentials and magic numbers, which exercise the API's success and error responses without sending a real message, then against a live number and the team's own phones before a customer ever gets a text.
The stakes
What does a bad Twilio integration cost you?
More than the build, because integrations fail without setting off an alarm. Nobody gets a message saying the numbers stopped agreeing. Somebody notices at month end, and then nobody trusts either system until it is proven again. The failures below are the ones worth designing against from the start.
- Carrier filtering is silent. An unregistered number, or a registered one sending messages that don't match its campaign, gets filtered without throwing an error you can see. Your system shows reminders sent. Customers get nothing. The first symptom is a no-show rate that climbs for weeks before anyone thinks to doubt the texts.
- A message goes to someone who opted out. Every one of those carries legal exposure under the telemarketing rules, and the complaints they draw wreck the number's reputation. Then the reminders customers actually wanted start getting filtered too.
- Replies land where nobody looks. A customer answers a reminder asking to move the appointment, the reply sits in a console somewhere, and the slot goes unfilled while the record shows a reminder dutifully delivered. Two-way texting without routing is a promise you can't keep.
The order of work
What happens, in what order, on a Twilio integration?
In this order, every time. The mapping comes before the code, and the reconciliation comes before we call it done. Nothing here is a date. The sequence is fixed, and the runway is set in your written scope once we have seen your actual data.
- 01
Register the number first
A2P 10DLC registration is the long pole, so it starts before the code does. We help you file the brand registration with your business details, and the campaign registration that describes what you'll send, with real sample messages and the consent language behind them. If a toll-free number fits better, it goes through its own verification. Nothing customer-facing sends until that clears. Unregistered traffic gets filtered, and the filtering is silent.
- 02
Write down what a message is
Every outbound message gets tied to a trigger and a record before anything is built. Which status change sends what, from which number, inside which hours, and what happens when the customer replies. The opt-out rule is written down here too, as a check on the customer record that every sending path has to run. That table is the scope, and your office manager can read it and correct it.
- 03
Build against test credentials
Twilio publishes test credentials and magic numbers that simulate a delivery, a failure and an invalid number without sending anything real, and the first version of the integration runs entirely against them. Status callbacks are wired from the very first message, so delivery tracking never becomes an afterthought. Then a live number texts the team's own phones through every flow before a customer sees anything.
- 04
Make repeats harmless
Each send gets recorded against the record and the event that caused it before the request goes out, so a retry after a timeout can't text the same customer twice about the same job. Inbound webhooks are checked against Twilio's signature before we trust them. Sends queue and drain at the throughput your registration allows, failed calls back off, and anything still failing lands in a queue with its reason attached.
- 05
Go live and watch the delivery rate
The number goes live and the monitor watches from the first message. It alerts on a spike in undelivered messages, on status callbacks going quiet, on a queue that stops draining, and on a day of silence when there should have been traffic. The delivery report keeps running on a schedule and a person reads it. In messaging, the dangerous failure looks like calm.
Limits
What we will not do
Cheaper to hear now than to discover halfway through. If one of these is what you are actually after, we will say so on the first call rather than take the work.
- We won't send to a list that never opted in. A purchased list, or a spreadsheet of numbers collected for something else, is legal exposure and a flagged number waiting to happen. The consent question gets answered before the first message goes out, and where the answer is no, the message doesn't go.
- We won't build a way around an opt-out. STOP stops everything, the opt-out lives on the customer record, and every sending path checks it. There's no override flag, and we won't add one if you ask. The exposure gets counted per message, and the customer's trust doesn't come back.
- We won't launch on an unregistered number to get moving while the paperwork catches up. Unregistered traffic gets filtered, the filtering is silent, and the damage lands on your number's reputation. Registration goes first even though it's the slow, boring part.
Questions
What people ask about Twilio integrations
Do we have to register before we can send texts?
For US texting from a regular local number, yes. Carriers require the business and the messaging use case to be registered before they'll allow application traffic, which the industry calls A2P 10DLC, and they filter numbers that skip it. The registration wants your business details including your EIN, a description of the messages you'll send, and the consent language your customers see. Toll-free numbers go through a different verification with the same idea behind it. We prepare the filing with you and submit it at the start of the build, because carrier approval is the part of the schedule nobody controls.
Can customers text back, and who sees the reply?
Yes. When a customer replies, Twilio posts the message to the integration, which writes it to the customer record and notifies whoever should answer, the dispatcher, the office, or the person assigned to the job. The whole conversation sits in one thread on that record, so anyone who opens the customer sees what was said and when. Nobody's passing a personal phone around. A reply that comes in after hours is on the record in the morning. It doesn't go home in somebody's pocket.
How are opt-outs handled?
As a hard rule, in more than one layer. Twilio stops further messages to a US number that replies STOP, and we treat that as the floor. The opt-out also gets written to the customer record, and every path that can send a message checks it first, so an automation somebody builds a year from now inherits the block. HELP replies get a real answer, consent is recorded with when and how it was given, and quiet hours go into the scope as a rule the system enforces. There's no override.
Can we text from our existing business number?
Often, yes. A landline or toll-free number that only takes calls today can usually be enabled for messaging, so customers text the number that's already on your trucks and your invoices. Whether yours qualifies depends on the number and the carrier it sits with, and we check that during scoping. We won't promise it up front. If it can't be enabled, a new local number in your area code does the job, and your existing number keeps handling calls exactly as it does now.
How do we know a message actually arrived?
Every message we send asks Twilio to report its delivery status back, and the integration writes that status onto the record that triggered the send. Delivered means the carrier reported it delivered, which is the strongest signal the network gives, and carriers differ in what exactly they confirm. Undelivered comes back with a reason. A bad number, a filtered message, a carrier problem. Those get flagged, so somebody picks up the phone before the reminder that never landed turns into a no-show. The delivery report tracks the rate over time, because a slow slide in deliveries is how filtering and stale numbers announce themselves.
Can we send a blast to our whole customer list?
To the part of it that opted in, and we'll ask to see the consent behind the list before we build the send. Reminders and updates about work a customer booked stand on solid ground. Marketing to numbers collected for something else is where the legal exposure lives, and a burst of unwanted texts draws the complaints that get a number flagged. There's a practical limit too. Throughput on a registered local number is capped, so a large list drains at the allowed rate and the integration paces it without erroring. If campaigns are the goal, say so early, because your registered use case has to match what actually gets sent.
Does this cover WhatsApp too?
Yes, through the same Twilio account and onto the same customer record. WhatsApp brings rules of its own. After a customer messages you, the business can reply freely inside the conversation window that opens. A message the business starts outside that window has to use a template WhatsApp approved in advance, so those templates get written and submitted as part of the build. It earns its keep with customers overseas and customers who simply live in WhatsApp, and the integration treats it as one more channel on the record.
Who owns the Twilio account, and what does Twilio charge?
The account is yours, opened in your name with your payment method, and Twilio bills you directly for messages, voice minutes, phone numbers and the carrier fees that come with registered A2P traffic. We work through API keys you create and can revoke, and the credentials live in a secrets vault, never in code. We don't resell the traffic or sit between you and the bill. The integration code lives in your repository, so any developer can pick it up later, and the number, the message history and the account go nowhere.
Related
Where this fits
An integration is rarely the whole job. Usually it is one part of a CRM, an operations system, or a client portal that needs Twilio to agree with it.
Tell us which two systems disagree
Book a strategy call, or send a short note about what gets retyped today and where the numbers stop matching.