These two terms get used as though they were competing products. They are not. One is infrastructure, the other is the way in.
What is the actual difference?
A gateway connects to the mobile networks; an API is an interface for reaching a gateway.
An SMS gateway holds the relationships and connections that let a message reach carriers: agreements, routes, numbers, and the operational work of keeping delivery healthy in each market. An SMS API is a programmatic interface, usually HTTP, for handing a message to something that can deliver it.
They sit at different layers, so a single product is normally both: a gateway with an API in front of it. The SMPP reference treats the relationship as unremarkable, describing SMPP itself as "used as an access protocol, or SMS API, by SMS gateways worldwide", and notes that gateways commonly offer several interfaces at once:
Other SMS APIs such as HTTP, SMTP and XML are also often offered.
So the interface is a choice about how you integrate, while the gateway is what determines whether messages arrive.
Which interface should I use?
HTTP, unless you have a specific reason not to.
| HTTP API | SMPP bind | |
|---|---|---|
| Connection | One request at a time, stateless | A session you open and hold |
| You manage | Retries and idempotency | Reconnection, windowing, sequence numbers, keepalives |
| Inbound | Webhooks | Operations on the same connection |
| Suits | Almost everything | Sustained high volume, multi-provider routing, existing SMPP estate |
What is SMPP covers the older interface and the narrow cases where it still earns its cost. For everything else the HTTP API gives you the same delivery with less to own, and whether to use an SDK or call the API directly is the next question down.
What should I actually compare?
Not the interface, which is the easy part, but what the gateway absorbs on your behalf.
The API surface of two providers will look similar: post a recipient, a sender and a body, get an identifier back. What differs is everything behind it.
- Number supply and registration. Buying a number is easy; getting it permitted to send in a given market is the work. Sender types and the registration each needs are where providers actually differ.
- Per-country rules. Which sender types a destination carries, what consent model applies, whether there are quiet hours. Bird publishes these per country on the destinations page rather than leaving you to discover them.
- Failure detail. A failure that says only "failed" cannot be acted on. Why SMS messages get filtered is an example of reporting that names causes, including the ones the platform does not yet distinguish.
- Throughput. A published ceiling per destination and sender type, rather than a limit you find under load. What is SMS throughput covers the two separate limits involved.
Why is sending asynchronous either way?
Because delivery does not happen during your request, whichever interface you use.
An SMS is handed to a message centre that stores it and forwards it when the handset is reachable, which can be seconds or hours later. What is an SMSC covers that machinery. No API can wait for it, so both interfaces do the same thing: accept the message, return an identifier, and report the outcome afterwards.
Bird's SMS overview and sending guide cover the shape on the HTTP side, including what a 202 means and where the outcome turns up. The single most common integration mistake is treating the response to the send as the delivery result: it is a receipt for the request, and nothing more.