Send UK SMS from your own code

The WorldText HTTP API is the same endpoint set whether you are sending to a UK mobile, a UK fixed-line-style number or an international destination, so a UK rollout is a configuration decision rather than a second integration. Every account gets its own credentials, and traffic is authenticated over HTTPS rather than shared tokens. The API is documented at the developer reference as a rendered OpenAPI specification, with a practical overview at the HTTP API guide for engineers who want the request and response shapes without wading through a schema first.

Sending to the UK takes the same shape as sending anywhere else: destination, message content and sender. The sender field is where the market difference appears, because UK senders commonly use an alphanumeric ID such as "ACME LTD" rather than a number, and that ID is subject to network reserved lists described on our UK SMS gateway page. The API accepts the identifier you choose; we handle what the networks allow.

Per-account credentials and HTTPS also mean your messages cannot be mistaken for another customer's, and receipts can never be routed to the wrong application. That separation matters when the same script sends both a one-time code and a delivery update.

Sending a message is not the same as delivering it, and UK business traffic should never be treated as fire and forget. WorldText reports delivery receipts through a callback URL configured in the portal Configuration tab, so your application receives an asynchronous notification when the network accepts, delivers or fails the message. The message state and error reference documents every state and error code, including the transient conditions that justify a retry and the permanent ones that do not.

Receipts are also how you build confidence in a sender ID change. If a reserved list substitutes your alphanumeric ID, the receipt and sender reporting will show it, which is why we advise checking sender IDs before launch rather than discovering substitutions months later. For engineers, the callback contract is idempotent by design: you should always handle a receipt by message ID, not by content, because duplicate callbacks are a normal condition to absorb.

UK mobile numbers use the same character sets as the rest of the GSM world, so the API's encoding controls apply unchanged. The default encoding dcs 0/1 is GSM-7, which carries 160 characters per part; dcs 8 selects UCS2 for Unicode content, which carries 70 characters per part. Concatenated multipart messages follow the standard limits of 153 characters per part in GSM-7 and 67 characters per part in UCS2, because the remaining characters carry the segment header.

Getting this wrong is the classic source of surprise billing: a message that looks like one part can become several after you add an apostrophe that lives outside the GSM-7 set, and multipart messages are charged per part. Test against the SMS length guide and the GSM character set page before you ship, and consider whether your content genuinely needs Unicode. A fixed-width field that forces UCS2 can double the effective cost of every UK message you send.

HTTP is the right answer for most UK traffic, but some workloads need a persistent connection with session-level flow control. WorldText offers SMPP v3.3 and v3.4 on request for approved accounts; activation is usually completed within 24 hours, but SMPP is not available on trial accounts, so request it when you know the traffic is real. A free SMSC simulator is included for testing. The simulator accepts and reports messages but does not deliver them to phones, which makes it ideal for exercising your queue logic without spending credits. See the SMPP service page and the SMPP codes reference for protocol detail. Helper SDKs are available for Java, C, C++, Perl and VB to cut the boilerplate out of integration.

A common development pattern is to exercise the full queue and retry path against the simulator first, then point the same code at real UK numbers once the handling is verified. That keeps test traffic free and production traffic predictable: the simulator accepts and reports, but never delivers, so your code has to handle every outcome before it touches a live recipient. SMPP accounts are activated once traffic is real, which means the queue design you validated over HTTP carries across to a persistent connection without rework.

The API is where UK market reality meets code. An alphanumeric sender ID identifies your brand but cannot receive replies, so a two-way application sends from a reply-capable UK number and receives inbound messages on the same connection. Our two-way SMS page covers the number side of that design, and the inbound SMS page covers receiving-only options such as SIM hosting.

Consent handling is an application concern in the UK. PECR determines what counts as marketing, so your code should distinguish transactional and marketing sends at the point of creation, because that is the boundary a compliance audit will probe. Our UK compliance page explains the rules in the language an engineer can implement.

One practical note on sender IDs: an alphanumeric ID is not a reply address, so if the UI invites a reply, the API call must use the virtual number as sender and the inbound callback must be handled on the same account. The developer reference documents both directions under one account model, and the HTTP API guide shows the inbound callback alongside outbound submission, which is why the two are best designed together rather than in separate tickets.