The messages UK customers expect on time

Transactional SMS is a service message triggered by an event. The event might be a login attempt (one-time code), an order placed (confirmation and tracking), a booking (appointment reminder), a delivery out for signature, a meter reading, a server alert or a payment failure. The defining property is not the content: it is that the message answers a question the recipient already has. Nobody asked for marketing, and nobody opts out of knowing their parcel arrived.

The category is why UK business users text at all. Transactional messages carry recognisable value, which is exactly why the UK market allows them without marketing consent. The transactional versus marketing comparison sets out the boundary in detail, and our UK business SMS page covers the broader use case. Maintaining the distinction is a systems discipline: if a service message is defined by its trigger rather than its wording, your compliance posture stays intact even as copy changes.

Transactional messages in the UK should be sent from an alphanumeric sender ID. Up to 11 characters, using letters, digits and spaces, the ID tells the recipient instantly, before they read a word, who is messaging. For a one-time code, that recognition is the difference between typing it in and ignoring it. It is the standard approach for UK transactional traffic, and it is why you rarely see a UK service message from a long number.

The usual caveats apply. UK mobile networks maintain reserved or restricted sender ID lists, and if your ID collides with one, the network may substitute or reject the message. BT/EE publish restricted lists, other operators are less open about theirs, and some networks want sender-ID registration through the aggregator before first use. Where a network requires it, we can check and register your sender ID. There is no US-style 10DLC mandate in the UK for the common case; the discipline is network list checks rather than national registration. See UK SMS compliance and the UK SMS gateway page for the operational detail.

A transactional message is only useful if it arrives, and arrival is not a promise you should take on faith. WorldText reports delivery receipts asynchronously through a callback URL configured in the portal, and the message state and error reference documents each state and error code so your systems can retry the conditions that make sense to retry and stop hammering the ones that do not.

Receipts do another job: they catch sender problems early. If a reserved list substitutes your alphanumeric ID, the reporting will show it, which is why we recommend checking sender IDs before launch rather than after a support ticket. For the integration itself, the UK SMS API page covers submission, encoding and callbacks in one place, and the developer reference is the source of truth for request and response shapes.

For a service message, verify delivery before release, not after. Send to a real UK number, watch the state transition, and only trust the flow once you have seen a receipt for the exact content your application produces. A one-time code that fails silently costs a login; a receipt costs nothing.

The UK treats the two categories differently, and the difference matters commercially. PECR, the Privacy and Electronic Communications Regulations, governs electronic marketing in the UK. Marketing by text needs consent or the soft opt-in exception: your own customer, similar products or services, with a clear opt-out offered at collection. That exception applies to email and text, and UK GDPR separately requires a lawful basis and a working opt-out for processing.

Transactional messages are not marketing, and do not need marketing consent. Privacy law still applies to the data inside them, so a sensible deployment records who was sent what and when, and keeps the data-processing story straight. Our UK compliance page walks the rulebook, and the compliance guide is the general reference: it is an overview rather than legal advice, but it is honest about where responsibility lies. Customers remain responsible for consent; we provide the platform and the sender-ID checks.

Transactional messaging usually comes from a system, not a person, and the integration should fit the system you already run. Most customers integrate through the HTTP API or SMPP, both of which the developer reference documents. SMPP v3.3/v3.4 is available on request for approved accounts and is usually activated within 24 hours; it is not available on trial accounts, so request it once traffic is real.

Legacy and monitoring systems have a lower-friction route: email-to-SMS. Messages are sent to an SMTP address and delivered as text messages, which is why Nagios SMS alerts and similar alerting setups work without a code change. The SMTP API guide covers the single-message form and the SMTP bulk API covers batch submission. For UK alerts and service messages, that is often the fastest safe path.

Whichever route you pick, keep the transactional flag attached to the message in your own records. It is the single piece of evidence that separates a service message from a marketing one if a consent question ever arises, and it costs nothing to add at the point of creation.