# What an SMS Gateway Is — and How to Choose One That Delivers > An SMS gateway bridges your application and the mobile networks. Here's what it does, and how to weigh SMPP vs HTTP, hosted vs dedicated, throughput, routing and SLA. - Canonical URL: https://www.broadnet.me/blog/what-an-sms-gateway-is-and-how-to-choose-one-that-delivers - Language: en - Last updated: 2026-10-10 - Publisher: BroadNet (https://www.broadnet.me) - Published: 2018-08-28 - Author: BroadNet Engineering ## What an SMS gateway actually does An SMS gateway is the bridge between an application and the mobile networks that carry text messages. Your software speaks in web protocols and structured data; operators speak in signalling protocols built for telecom. The gateway translates between the two — accepting a message from your system, formatting it for the destination network, submitting it over the right route, and returning the network's response so you know what happened. That translation hides a surprising amount of complexity: number validation and formatting to E.164, character-set handling (GSM 7-bit versus UCS-2 for non-Latin scripts), message segmentation for long texts, sender-ID rules that vary by country, and the return path for delivery receipts. A good gateway makes all of this predictable. A weak one leaks the complexity back to you as failed sends and silent drops. ## SMPP binds versus HTTP APIs There are two common ways to connect. The first is SMPP (Short Message Peer-to-Peer), the protocol operators themselves use. You open a persistent TCP session — a "bind" — as a transmitter, receiver, or transceiver, and stream messages over it. SMPP is efficient at high volume, gives fine-grained control over message parameters, and delivers receipts asynchronously over the same session. It is the right choice when you send continuously at scale and want the lowest overhead per message. The second is an HTTP/REST API. You send a message as a simple HTTPS request and receive a JSON response; delivery receipts arrive via webhook. REST is far easier to integrate, fits modern stacks and serverless functions, and needs no long-lived connection. For most application traffic — one-time passcodes, notifications, alerts — it is the pragmatic choice. Neither is universally better. Teams sending millions of messages a day often bind over SMPP for throughput and control; teams shipping features quickly reach for REST. The strongest position is to have both available, so the protocol follows the workload rather than the other way around. ## Hosted versus dedicated A hosted (shared) gateway means your traffic runs on the provider's shared infrastructure and routes. It is fast to start, requires no capacity planning, and scales elastically. For most senders it is entirely sufficient. A dedicated setup gives you isolated capacity — a dedicated SMPP bind, reserved throughput, sometimes dedicated routes or numbers. It costs more and takes longer to provision, but it insulates you from noisy neighbours, makes throughput predictable, and is often required for regulated or high-security workloads. The decision comes down to volume, predictability, and compliance — not prestige. Choose dedicated when consistent TPS and isolation genuinely matter; otherwise hosted is the simpler answer. ## Throughput, TPS, and delivery receipts Throughput is usually quoted as TPS — transactions (messages) per second. It matters most when a burst has to clear in a narrow window: a flash alert, a scheduled campaign, a wave of login codes. Headline TPS is meaningless without two qualifiers: whether it is sustained or peak, and whether the downstream operator route can actually absorb it. A gateway can accept 1,000 TPS from you and still queue behind a route that clears far slower. This is where delivery receipts (DLRs) earn their keep. A DLR is the network's confirmation of a message's final state — delivered, failed, expired, or rejected. Treat "submitted" and "delivered" as different things: submission means the gateway accepted your request; delivery means the handset received it. Instrument both, reconcile them, and alert on the gap. When DLRs stop arriving or delivered rates fall, you have found a routing problem before your users do. ## Routing quality and grey routes The single biggest differentiator between gateways is routing — the path a message takes to reach the destination operator. Direct connections to operators produce clean delivery, reliable sender-ID handling, and honest DLRs. Cheap, indirect paths — often called grey routes — exploit loopholes to lower cost. They look attractive until operators close them: messages then get filtered, sender IDs get rewritten, receipts become unreliable, and traffic can be blocked without warning. For anything that matters — passcodes, transaction alerts, account notifications — routing quality is not a luxury. A provider's operator footprint is the thing to scrutinise. BroadNet's network spans 200+ countries with 1,000+ direct operator connections built up since 2003, and that direct reach is precisely what keeps critical messages arriving intact. ## SLA, security, and how to evaluate a provider Finally, read past the feature list. An SLA should state availability, support response times, and what happens when targets are missed — not merely promise "high reliability." On security, look for encrypted API transport, authenticated and IP-restricted SMPP binds, sensible credential management, and clear data-handling practices. Ask how failover works across routes, how the provider handles operator outages, and whether reporting gives you real visibility into delivery. A gateway is infrastructure. Judge it the way you would judge any dependency your product leans on: by the protocols it speaks, the routes it owns, the receipts it returns, and the guarantees it will put in writing.