The actual logic that is involved with processing a single SMS is not exactly trivial, but here is an overview of how the messages and delivery reports travel through our systems.
Sending SMS Messages¶
Messages being sent to mobile devices, also known as MT SMS. Most often, these are notifications from systems or services to a person, but other kinds of traffic also fit this category.
The API receives the request and performs a series of validation processes. Assuming that the data adheres to our schemas, it is passed to the queue and processing systems.
The schema performs several checks, but it is important to note that it does not check whether an SMS is deliverable, simply because that would take too long to fit within the time frame of an API request. Instead, once the API has verified that the SMS can be sent, it is passed to the next step.
Processing is the heart of the system. Here, the SMS is saved in our databases and routed to operators based on the recipient MSISDN and sometimes specific customers preferences.
This is also the step where we have the time to perform a number of checks, such as running each SMS through filters that look for malicious use, and reject the SMS, if there is a match.
The SMS is forwarded to a specific connection. Some use SMPP and others a custom HTTP connection. Some connections are able to absorb more traffic than others, but in the end most operators impose a limit on how many SMS messages can be submitted in a given time interval.
Once the SMS has been accepted by the operator or gateway that we routed to, we start receiving status reports. These reports are then passed to the processing system, where the destination of the delivery report (if any) is looked up. The report is subsequently passed on to the webhook system.
Sending a delivery report is actually just a content encoding step and a HTTP request. The complexity arises from imposing a throttle, which ensures that most reports arrive safely instead of the server receiving too many requests than it is able to respond to.
This covers messages sent from devices also known as MO SMS. They most often come in the form of replies to a previous MTSMS from a service as explained above.
When an MOSMS arrives to our system via one of our many connections, the system backing the connections performs a number of very basic validation processes and forwards it to processing.
We either use the recipient number to determine the message destination, in case the whole number is owned by a single customer, or we extract the keyword (the first word in the message text itself) and use the recipient number in combination with the keyword, in case it is a keyword on a shared number.
Once the message destination is determined, we pass the message over to delivery.
Final message delivery happens either to the customer’s webhook or via a connected SMPP connection, depending on how it is configured.