A UK SMS gateway built around delivery you can verify

A gateway is the unglamorous middle of SMS: the bit between your application and the phone. Every UK text message you send has to reach the right network, be accepted or rejected by that network, and report back what happened, and none of that is part of your product. WorldText's gateway takes on those tasks so you do not have to arrange carrier connectivity, negotiate delivery contracts or maintain retry logic against each network's quirks.

Concretely, that means message submission over HTTP or SMPP, routing to UK networks, delivery receipts returned to you asynchronously, and retries structured around the documented message states and error codes rather than blind resends. It also means the sender side: handling alphanumeric sender IDs, checking network reserved lists and, where a network requires it, registering the ID before first use. None of that shows up in a demo, and all of it decides whether a UK customer actually receives your message.

If you already run an application that sends email, the gateway is the SMS equivalent of your relay: a protocol boundary you do not want to own. See the UK SMS API page for the developer-facing detail.

UK messaging means understanding that the United Kingdom is not one network. Traffic terminates on a range of operators with different characteristics, and a gateway exists to smooth over those differences rather than expose them. WorldText's coverage page lists UK networks explicitly, including EE, O2, Three, Vodafone and Sky, plus MVNOs that piggyback on the major networks, and fixed-line style numbers such as the 994 range. If a destination is listed, it is one we can reach.

The practical consequence for a UK sender is that you should never have to think about which operator a number belongs to. You submit to the gateway, and delivery to that network is handled for you. What you do need to know is cost, and the answer is deliberately boring: UK destinations are 10.71 credits per single-part message, with multipart messages charged per part and credit bundles purchased in GBP including VAT. See the pricing page for the bundle structure. No other fee appears in our marketing copy because no other fee is hidden in the portal.

Sender handling is where UK gateway operations differ most from a typical international setup. The default UK business sender is an alphanumeric ID up to 11 characters: your brand, or a service name, displayed in the inbox. The gateway must carry that ID without mangling it, and it must also warn you when a network may not accept it.

UK mobile networks maintain reserved or restricted sender IDs. If your ID collides with a reserved entry, the network may substitute another sender or reject the message, and BT/EE publish restricted lists rather than leaving you to guess. 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 with the networks; that is genuinely part of operating a UK gateway, not an upsell.

The complementary rule: an alphanumeric sender cannot receive replies. If your UK traffic needs a conversation, send from a reply-capable number and pair the gateway with our two-way SMS service. The compliance page covers the sender-ID rules alongside the PECR picture.

WorldText offers both a portal and an API because different workloads suit different interfaces. Use the portal when a human is sending: an ad hoc alert to a colleague, a test message before a campaign, checking whether a number has come back into service. Use the gateway when a system is sending: transactional alerts, one-time codes, monitoring notifications, anything with volume and repetition.

The gateway interface is documented at the developer reference and driven through per-account credentials. The portal remains the place for configuration, including the callback URL that receives delivery receipts. If you are sending from an application, the answer is rarely the dashboard; the dashboard is for verifying the application.

As a rule of thumb, anything a person might need to send once a week belongs in the portal, and anything that will run unattended belongs in code. A common mistake is to automate in the dashboard: export, upload, hope. The gateway exists to remove that pattern, and the developer reference plus the HTTP API guide are the documentation set for it. If you are unsure which route fits, send a test message both ways; the receipts usually settle the argument quickly.