A notification service needs both a way to submit texts and a route to recipients' phones. Choosing an interface answers only the first part of that problem.
What does each part do?
An API accepts programmatic requests. A gateway bridges your application and mobile networks.
Your application submits a recipient, sender and message through the interface. The gateway passes messages toward the network services that deliver them. A provider can supply both parts in one service.
The SMPP gateway reference describes gateways connecting applications with mobile message centers. It also describes gateways offering several interfaces, including HTTP and SMPP.
The interface does not determine every delivery capability. A convenient request format cannot make an unsupported sender valid in a destination.
Which interface should I choose?
Choose HTTP for a new application unless an existing SMPP integration or specific connection requirement justifies managing SMPP.
With HTTP, your application makes requests and processes responses. It still needs retries, duplicate-send protection and delivery-event handling.
SMPP uses a connection that remains open. Your client authenticates a session and handles connection loss, acknowledgments and incoming operations. SMPP explains that work.
An existing SMPP system can make that interface a practical choice. Test the provider's supported operations and limits before assuming another SMPP connection behaves identically.
What delivery capabilities should I compare?
Compare destination coverage, permitted senders, throughput and useful failure reports against your application's needs.
- Destinations: confirm support for every country you serve, since one working route does not establish another.
- Senders: check availability and registration before committing to the identity recipients will see.
- Throughput: distinguish request limits from the rate at which the delivery path can carry traffic.
- Events: verify how incoming messages and delivery failures reach your application.
Bird's destination pages publish country-specific requirements. Sender types explains the identity choices.
Why does delivery arrive separately from acceptance?
The network can finish delivery after your submission request completes.
A message center can retain a text while a phone is unreachable. Message centers explains that waiting stage.
Keep submission and delivery as separate results in your application. Otherwise an accepted request can appear successful even when a later delivery report records failure.
How do I send through Bird's HTTP API?
You submit a message, save its identifier and process the delivery events that follow.
Use POST /v1/sms/messages with to, from, text and category for a free-text send. Set category to one of marketing, transactional, authentication or service. The sending guide documents the supported fields.
A 202 response confirms acceptance. It does not confirm delivery to the phone. Track the returned id through SMS events so the eventual result updates the correct request.
Which path fits my application?
Choose the interface your application can operate reliably, then verify the delivery capabilities separately.
- Use HTTP for a new integration that has no specific SMPP requirement.
- Use SMPP when an existing system or required connection behavior justifies its session management.
- Test the destinations, senders and delivery events before committing traffic to either path.
In short
The API and gateway perform different jobs.
The API accepts your request, while the gateway provides the path toward the mobile network.
HTTP avoids managing an SMPP session.
SMPP requires connection recovery and session handling in addition to your message workflow.
Acceptance and delivery remain separate.
A successful send request does not establish that the recipient received the message.
Compare the delivery path as well as the interface.
Check destination support, sender requirements, throughput and failure reporting before choosing an integration.