Twilio SMS API Integration: A Complete Guide for UK Businesses

The Twilio SMS API is one of the most straightforward integrations available — a single API call sends an SMS to any UK or international number, and a webhook endpoint receives inbound replies. Despite the simplicity, the range of things you can build with it is wide: appointment reminders that reduce no-shows, order notifications that keep customers informed, two-factor authentication that secures your platform, payment alerts that chase unpaid invoices. This guide covers how the Twilio SMS API works, what UK businesses need to know about sender registration, and what a properly built integration looks like.

How the Twilio SMS API works

Sending an SMS with Twilio is a single HTTP POST request to Twilio’s API endpoint. The request includes your Twilio Account SID and Auth Token for authentication, the recipient’s phone number, the sender number or name, and the message body. Twilio delivers the message through its carrier network and returns a delivery status. That’s the core of it.

The API is deliberately simple. Most of the complexity in a Twilio integration isn’t the API call itself — it’s the surrounding infrastructure: the trigger logic that decides when to send, the dynamic content that personalises the message, the error handling that catches delivery failures, and the inbound webhook that processes replies. A well-built integration wraps the simple API call in robust, well-tested application logic.

Twilio provides official client libraries for every major language — PHP, Python, Node.js, Ruby, Java, C# and others. These libraries handle authentication and serialise the API requests, reducing the boilerplate code required. The underlying API is REST-based and can be called directly without a library if preferred.

Authentication

Twilio uses Account SID and Auth Token authentication — the two credentials are available in your Twilio console and sent as HTTP Basic Auth credentials on every API request. These credentials must be stored server-side only. They should never appear in client-side JavaScript, mobile app source code, or version control. A server-side proxy pattern — your platform calls your own server, your server calls Twilio — keeps credentials protected.

For production integrations with multiple services or team members, Twilio also supports API keys as an alternative to the master Auth Token. API keys can be created with limited permissions and revoked individually without affecting other integrations — better practice than sharing the master credential.

UK phone numbers and sender ID

To send SMS in the UK, you need either a Twilio UK phone number or an approved alphanumeric sender ID. Understanding the difference matters for the type of messaging you’re building.

UK long number — a UK mobile or landline number provisioned through Twilio. Supports two-way messaging (customers can reply). Required for any conversational use case — appointment confirmations where customers reply Y or N, support conversations, keyword responses. Costs a small monthly rental through Twilio.

Alphanumeric sender ID — your business name appears as the sender instead of a number (e.g. “AcmePlumbing” instead of a phone number). One-way only — customers cannot reply. Best for transactional notifications where replies aren’t needed. Requires registration with Twilio and approval for UK delivery.

Shared short codes and toll-free numbers — less common for UK business integrations. Short codes (5-6 digit numbers) are typically used for high-volume consumer messaging campaigns. Toll-free numbers are primarily a US concept.

UK A2P SMS registration

This is the part that catches businesses out. Twilio now requires UK businesses to register their sender identity for Application-to-Person (A2P) SMS. Without registration, messages may be filtered or blocked by UK mobile networks. The registration process involves submitting your business details to Twilio, which then registers them with the relevant UK carrier programmes.

Registration isn’t technically complex — it’s a form submission in the Twilio console — but it takes time to be approved, typically several days to a couple of weeks. This is something to start before the integration build begins, not after. The integration can be developed and tested in the sandbox while registration is pending, but going live requires approved registration for reliable UK delivery.

The registration requirements vary depending on your use case — transactional messaging (order confirmations, appointment reminders) has different requirements from marketing messaging. Most business integrations fall into the transactional category, which has a more straightforward approval path.

Inbound SMS and webhook handling

For two-way messaging, Twilio calls a webhook URL on your server whenever an inbound SMS is received on your number. The webhook receives the sender’s number, the message body, and metadata. Your integration processes the message and optionally returns a TwiML response with a reply.

Common inbound SMS patterns: a customer replies Y to confirm an appointment, N to cancel; a customer texts STOP to unsubscribe; a customer texts a keyword to trigger an action. Each pattern requires explicit handling in the webhook — parsing the message body, checking the keyword or response, taking the appropriate action in your system, and optionally sending an automated reply.

Webhook security matters. Twilio signs every webhook request with your Auth Token. The integration should verify this signature before processing any incoming message — rejecting requests that aren’t genuinely from Twilio.

Delivery status callbacks

Twilio can notify your server when an SMS delivery status changes — sent, delivered, failed, undelivered. Setting a status callback URL on outbound messages gives your integration visibility into whether messages actually reached the recipient.

Delivery status is useful for several purposes: logging delivery confirmation for compliance (particularly relevant for healthcare and financial services); flagging undelivered messages for follow-up by another channel; alerting your team when a significant number of messages fail delivery, which might indicate a number formatting issue or carrier problem.

UK delivery confirmation is generally reliable for messages to valid UK mobile numbers. Landline numbers will fail (they can’t receive SMS), and formatting errors in phone numbers — missing country code, wrong number of digits — produce immediate failures that the status callback catches.

For the full service and pricing, see the Twilio SMS API integration service. For appointment reminders specifically, see SMS appointment reminders with Twilio. For two-factor authentication, see Twilio two-factor authentication. For what the build costs, see the Twilio SMS integration cost guide.

Related posts

• SMS appointment reminders with Twilio
• Twilio two-factor authentication via SMS
• Twilio WooCommerce SMS notifications
• Twilio SMS API integration cost

Message formatting and character limits

Standard SMS messages are limited to 160 characters using the GSM-7 character set. Messages longer than 160 characters are automatically split into concatenated segments and reassembled on the recipient’s device — most modern phones display them as a single message. Each additional segment costs an additional per-message charge. A 320-character message costs twice the per-message rate.

Unicode characters — emoji, accented characters outside the GSM-7 set, non-Latin scripts — reduce the single-segment limit to 70 characters. A message containing a single emoji that would otherwise be 160 characters becomes two segments. For integrations where message content is dynamic and might include user-generated text, this is worth building a character count check into the message formatting logic.

Dynamic message content should always be tested with edge cases: very long customer names, special characters in addresses, order references that include symbols. Messages that look fine in testing with clean data can break in production when real customer data is formatted unexpectedly. Thorough testing with a range of realistic message content is an important part of the build process.

Twilio Verify for OTP and phone verification

For two-factor authentication and phone number verification, Twilio Verify is a better option than building OTP logic on top of the basic SMS API. Twilio Verify handles code generation (6-digit codes by default), delivery via SMS or voice call, and validation through a separate API call. It includes built-in rate limiting, fraud prevention, and automatic fallback from SMS to voice if SMS delivery fails.

Using Twilio Verify rather than rolling your own OTP system avoids several common security mistakes: predictable code generation, codes that don’t expire, replay attacks, and brute-force attacks on code entry. Verify handles all of this correctly out of the box. The integration is a slightly different flow from standard SMS sending — start verification (sends the code), check verification (validates the entered code) — but straightforward to implement.

Twilio Verify is priced per verification attempt, separately from standard SMS charges. This is worth noting in scoping discussions — a platform with high registration volume will have ongoing Verify costs that scale with usage.

If you need help with a custom API integration for your website or business application, I can help. I build bespoke API integrations for UK businesses. See API integration pricing or get in touch to discuss your project.