--- title: "What Is an SMS Gateway? How It Works, Types and How to Choose" description: "What is an SMS gateway? See how a message travels from your app to a handset, the types (API, SMPP, email-to-SMS, GSM modem), key features and how to choose." canonical: "https://omnichannels.ai/blog/what-is-sms-gateway/" language: "en" updated: "2026-11-03" publisher: "BroadNet Technologies" brand: "OmniChannels.ai" category: "sms" primaryQuery: "what is an sms gateway" keywords: ["what is an sms gateway", "sms gateway api", "sms gateway vs sms api", "smpp gateway", "sms gateway how it works", "gsm modem sms gateway", "email to sms gateway", "bulk sms gateway"] published: "2026-11-03" author: "OmniChannels.ai Editorial Team" reviewer: "BroadNet Messaging Solutions Team" readingMinutes: 10 answer: "An SMS gateway is a system that converts messages between your applications and mobile networks. Your software submits a message over an HTTP API or SMPP, the gateway checks the number, picks the encoding and route, splits long texts and hands the message to the operator's SMSC, which delivers it to the handset. A delivery receipt then travels back so you can see the outcome." takeaways: ["An SMS gateway sits between your application and the operator's SMSC; it handles routing, encoding, segmentation, throughput control and delivery receipts.", "Four kinds are in use: HTTP API gateways, SMPP gateways, email-to-SMS gateways and hardware GSM modem or SIM-box gateways. Business-grade A2P traffic belongs on operator-connected software gateways.", "An SMS API is the developer interface in front of a gateway, and an SMPP bind is the persistent connection used for high volume.", "Sending business traffic through SIM cards can strip your sender ID, delay messages, break Arabic text and cause blocking, because it bypasses the operator's commercial agreement.", "Choose a gateway by route type per country, delivery receipt quality, sender ID handling, throughput, encoding support and a test you run with your own numbers before moving volume."] faq: - q: "What is an SMS gateway in simple terms?" a: "An SMS gateway is the system that carries a text message from your software into the mobile network. You send it a message through an API or SMPP, and it deals with number checks, encoding, splitting, routing and delivery reports. Without a gateway, you would need a separate connection to every mobile operator you want to reach." - q: "What is the difference between an SMS gateway and an SMS API?" a: "The SMS API is the interface developers call, usually HTTPS with JSON. The gateway is the platform behind it that routes the message to operators. One provider usually offers both, and SMPP is another way to reach the same gateway. When people say gateway API, they mean the API that gives your software access to gateway infrastructure." - q: "How does an SMS gateway work?" a: "Your application submits the message, the gateway validates the number, chooses GSM-7 or UCS-2 encoding, attaches the sender ID, splits long messages and sends it to the operator's SMSC over SMPP or another interface. The SMSC delivers to the phone. A delivery receipt returns, and the gateway maps it to a status such as delivered or failed." - q: "Is an SMS gateway the same as an SMSC?" a: "No. The SMSC is the operator's store-and-forward centre inside the mobile network, which holds and retries messages until they are delivered or expire. A gateway is the layer between your systems and one or many operators. Some gateways connect directly to operator SMSCs; others route through aggregators." - q: "Can I use a GSM modem or SIM box as an SMS gateway?" a: "Technically yes, for a few person-to-person style messages from your own SIM. For business traffic it is a poor fit: capacity is limited, sender ID options are poor and operators may detect and block SIM-based A2P traffic. Use an operator-connected gateway for OTPs, alerts and campaigns, and check the route type before you sign." - q: "What should I look for when choosing an SMS gateway?" a: "Ask whether routes are direct to operators, how delivery receipts are sourced, how sender IDs are registered in countries that require it, which encodings are supported, how throughput is agreed, how failover works and how you can test with your own numbers. Avoid decisions based only on price per message." sources: - title: "SMPP Protocol Specification v3.4, Issue 1.2 (12 October 1999), SMPP Developers Forum" url: "https://smpp.org/SMPP_v3_4_Issue1_2.pdf" - title: "3GPP TS 23.040: Technical realization of the Short Message Service (SMS)" url: "https://www.3gpp.org/ftp/Specs/archive/23_series/23.040/" --- # What Is an SMS Gateway? How It Works, Types and How to Choose Canonical: https://omnichannels.ai/blog/what-is-sms-gateway/ Language: en Publisher: OmniChannels.ai by BroadNet Technologies This guide is for developers, product owners and operations leads who need to understand what sits between their application and a customer's phone. You will learn the path a message takes, the kinds of gateway, the features that matter and how to send a first test message. ## What is an SMS gateway? An SMS gateway is a system that converts messages between applications and mobile networks, handling routing, encoding, segmentation and delivery receipts. It is the translation layer between your software and the operators that deliver to handsets. The term is used in two ways. It can mean a provider's platform that connects to many operators, or software and hardware that connects one company's systems to a provider. Our [glossary entry for SMS gateway](/glossary/sms-gateway/) gives the short definition. Two neighbouring terms are often confused with it: - **SMSC (Short Message Service Centre):** the operator's own network element that stores, forwards and delivers SMS. 3GPP TS 23.040 calls it the Service Centre. See [SMSC](/glossary/smsc/). - **SMS API:** the developer interface in front of a gateway. See [SMS API](/glossary/sms-api/). A gateway is the routing and translation layer between them, and one provider can play the roles of gateway, API provider and aggregator at once. ## How does a text message travel through an SMS gateway? A message goes from your application to the gateway, from the gateway to the operator's SMSC and from the SMSC to the phone, and a delivery receipt comes back along the same path. Here is the journey step by step. 1. **Your application submits the message.** It calls an HTTP endpoint or sends an SMPP `submit_sm`, with the destination number, sender ID and text. 2. **The gateway validates and normalises.** It checks the number format, applies country rules and may look up the number. 3. **It chooses encoding.** Plain Latin text uses GSM-7, with 160 characters in one segment. Arabic and other scripts need UCS-2, with 70 characters in one segment. Our [SMS character limits guide](/blog/sms-character-limits-unicode-arabic/) shows how this affects cost and length. 4. **It splits long messages** into segments that the handset puts back together. 5. **It selects a route** for the destination network and attaches the registered sender ID where one is required. 6. **It queues to respect throughput,** so it does not exceed what the operator agreed. 7. **It hands over to the operator's SMSC,** typically over SMPP. 8. **The SMSC delivers.** It asks the network where the subscriber is and forwards the message. If the phone is off, it holds the message and retries until the validity period ends. 9. **A delivery receipt returns.** The gateway maps it to a status and posts it to your webhook. A first response from the SMSC only says it accepted the message. The receipt later says what happened. A message with an accepted response and no receipt is not yet delivered and not necessarily failed. Our guide to [message delivery status](/blog/message-delivery-status-explained/) decodes the statuses. ## What are the types of SMS gateway? There are four types in common use, and they differ in how they connect and whether they are suitable for business traffic. | Type | How you connect | Typical use | Fit for A2P traffic | |---|---|---|---| | HTTP API gateway | HTTPS requests with JSON or form data, plus webhooks | Applications, OTP, notifications, marketing | Yes | | SMPP gateway | A persistent TCP session (a bind) | High volume, resellers, enterprises with SMPP clients | Yes | | Email-to-SMS gateway | Send an email to a special address or through a web form | Legacy systems and tools that can only send email | Limited: few controls over encoding, sender ID and receipts | | Hardware GSM modem or SIM box | Software drives SIM cards in a device | Small local tests, one-off alerts from your own SIM | No for business A2P | ### API gateways An API gateway is the usual choice. Your code makes an HTTPS call and receives a message ID, and the platform sends statuses to a webhook. It is stateless and easy to debug with standard tools. See our [SMS API examples](/blog/send-sms-api-examples/) for cURL, Node.js, Python and PHP. ### SMPP gateways SMPP (Short Message Peer-to-Peer) is an open binary protocol over TCP that applications, called ESMEs, and providers use to exchange SMS with an SMSC. Version 3.4 is the most widely deployed; the specification we cite is Issue 1.2 of 12 October 1999. A session starts with a bind as transmitter, receiver or transceiver. The client sends messages with `submit_sm` and receives inbound messages and delivery receipts as `deliver_sm`, and `enquire_link` keeps the session alive. Every request carries a sequence number, so many requests can be in flight at once, which is what makes SMPP efficient at volume. Pick SMPP when you already run SMPP software or send large volumes. Our guide to [SMS API vs SMPP](/blog/sms-api-vs-smpp/) compares the two, and the [SMPP bind](/glossary/smpp-bind/) entry explains the session types. ### Email-to-SMS gateways These let a system that can only send email produce a text. They are convenient for legacy tools, but you get few controls: encoding, sender ID rules and delivery reports are usually limited. Use them only as a stopgap and test delivery in each country. ### Hardware GSM modems and SIM boxes A modem or SIM box holds SIM cards and sends texts as if from ordinary phones. It works for a handful of messages, but for business A2P traffic it carries real risks, described below. ## Why should business SMS not go through SIM boxes? SIM-based sending bypasses the operator's commercial agreement, so the traffic can be delayed, rebranded or blocked. In messaging this is the technique behind many grey routes. Our entries on [SIM box fraud](/glossary/sim-box-fraud/) and [grey routes](/blog/grey-route-vs-direct-route-sms/) describe the symptoms: - Business messages arrive from a random local mobile number instead of the registered sender ID. - Messages arrive late, lose Arabic encoding or are blocked when the operator detects the SIMs. - Delivery receipts may be unreliable or fabricated by the gateway. - Sender ID registration rules in markets such as the UAE and Saudi Arabia are not met. The business that sent the message bears the risk, often without seeing it. A very low price is a warning sign. Ask for the route type per destination and test with your own numbers. ## What features should an SMS gateway have? A good gateway handles the boring parts reliably: delivery receipts, encoding, throughput and sender IDs. Use this checklist when you compare options. | Feature | Why it matters | Question to ask | |---|---|---| | Direct operator connectivity | Fewer hops, better delivery and traceability | Which destinations are direct and which are via partners? | | Delivery receipts and webhooks | You need to know what happened | Where do receipts come from, and what do statuses map to? | | Sender ID handling | Required or restricted in many countries | Who files the registration and what happens when it is rejected? | | Unicode and Arabic support | Arabic needs UCS-2 with shorter segments | Does the API count segments before sending? | | Throughput control | Prevents overload and throttling | How is sending speed agreed per account? | | Number lookup | Cleans lists and supports routing | Can I check numbers before I send? See [HLR lookup](/blog/hlr-lookup-number-validation/) | | Failover | A route can fail | What happens when one route degrades? | | Two-way SMS | Replies, opt-outs and conversations | Can customers reply and where do replies go? | | API and SMPP | Fit with your systems | Are both offered on the same routes? | | Scheduling and bulk jobs | Campaigns | Can I upload files and schedule sends? | | Fraud controls | Protection against SMS pumping | What limits and alerts exist? See [SMS pumping prevention](/blog/sms-pumping-fraud-prevention/) | ## How do I choose an SMS gateway? Decide on your traffic first, then test routes with your own numbers before you move volume. Follow this sequence. 1. **List destinations and traffic types:** OTP, alerts and promotions behave differently and are often registered separately. 2. **Check sender ID rules** for each country with the free [sender ID checker](/tools/sender-id-checker/). 3. **Decide API or SMPP.** Most applications use the API, and high-volume senders add SMPP. 4. **Ask for route type per country** and how delivery receipts are sourced. 5. **Run a test** with your own verified numbers in each target country. Check arrival time, sender display, Arabic rendering and receipts. 6. **Review support and escalation paths,** including who to contact when messages stop. 7. **Read the commercial terms,** including how sender ID registrations and prices are quoted. Our [bulk SMS provider checklist](/blog/choose-bulk-sms-provider/) goes further. The free [messaging provider RFP kit](/tools/messaging-provider-rfp-kit/) can turn this list into questions for suppliers. ## How do I connect to an SMS gateway and send a first message? Request test access, store your token securely, call the send endpoint and receive the delivery status on a webhook. With BroadNet there is no instant self-serve signup, so the first step is a short access request. 1. **Request test access.** [Tell us](/demo/) your channels, destination countries, expected volume and use case. An engineer issues test credentials and verifies the numbers you will test with. 2. **Store the token** in an environment variable such as `BROADNET_TOKEN` on your server. 3. **Send a message** with `POST /sms/sendSms` to `https://api.broadnet.me`, using the header `Authorization: Bearer `. 4. **Receive the status** on your HTTPS webhook. Statuses include SUBMITTED, SENT, DELIVERED, READ, FAILED and REJECTED. Handle duplicates and out-of-order events. ```bash title="cURL" curl -X POST https://api.broadnet.me/sms/sendSms \ -H "Authorization: Bearer $BROADNET_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "senderId": "OmniDemo", "destinationNumber": "447700900123", "message": "Your OmniDemo code is 482913", "messageType": "TEXT" }' ``` The full walk-through, with Node.js, Python and PHP, is in the [developer quickstart](/developers/quickstart/), the [SMS API reference](/developers/sms/) and the [webhooks guide](/developers/webhooks/). For SMPP, binds are provisioned per account and use TLS; see [SMPP connectivity](/developers/smpp/). ## What mistakes do people make with SMS gateways? Most problems come from assumptions about delivery and routes, not from the API call. - **Treating "accepted" as "delivered".** Wait for the receipt. - **Ignoring encoding.** One Arabic character can switch a message to UCS-2 and shrink the segment size. Use the [SMS character counter](/tools/sms-character-counter/). - **Skipping sender ID registration** in countries that require it. - **Buying on price alone.** Cheap routes can mean grey routes. - **Sending OTP and promotions on the same route** without separating them. - **Not planning for failover.** Ask what happens when a route degrades. - **Skipping fraud controls.** Unprotected OTP endpoints invite SMS pumping. ## Worked example: a Dubai delivery app "Rahal Express", a synthetic delivery app in Dubai, sends a login code, a driver-on-the-way alert and a weekly promotion. Their first gateway was an email-to-SMS bridge built into an old tool. Codes sometimes arrived after the session expired, Arabic names broke, and the app had no delivery statuses. They move to an API gateway: the app calls the SMS endpoint, the sender ID is registered where needed, Arabic text is counted as UCS-2 segments before sending, and statuses return to a webhook so the support team can see failures. OTP and promotional traffic use separate campaigns and sender IDs. They run a test on their own numbers in each destination before moving volume. The result is not magic; it is visible delivery, correct text and a clear owner for every message. ## How OmniChannels.ai helps OmniChannels.ai sends A2P SMS over BroadNet's direct operator connectivity, with two-way SMS, sender IDs, bulk sending, Unicode and Arabic, HLR number lookup and SMPP 3.4 for high volume. A REST API at `api.broadnet.me` reports delivery statuses in one webhook format, and our team prepares and files sender ID registrations with you. Test access goes to your own verified numbers. [Request access](/demo/) or read the [developer documentation](/developers/) to start. A gateway is one layer of a [CPaaS platform](/cpaas/).