We always aim to meet performance targets on SMS as we know that they are typically time sensitive notifications.
Why we have performance targets for SMS
Connect is our second product within the SMS space (previously PureSMS via Cedita) and we have learned a lot during the past 5 years of offering this service to customers.
Whilst it may not be important for customers sending order confirmations, delivery notices, or payroll information to customers, performance is important when OTPs are being sent or a two-way service is being implemented. With that in mind, we always aim to offer the best possible performance through our APIs.
The Targets
These targets are for our API Response time (ie. the time measured from the point at which you send a request and receive a response). This is measured for a UK network, and may differ when communicating with our API from different locations.
Time is measured for a single, GSM, message part per SMS.
SMS Count
Mode
Target
1
Single, Non-Template
200ms
1
Single, Template (Sent)
500ms
1
Single, Template (Stored)
250ms
1-50
Bulk, Non-Template
500ms
51-1000
Bulk, Non-Template
1000ms
1001-5000
Bulk, Non-Template
1500ms
5001+
Bulk. Non-Template
No specific target
1-1000
Bulk, Template (Sent)
2500ms
1001+
Bulk, Template (Sent)
No specific target
1-1000
Bulk, Template (Stored)
1000ms
1001-5000
Bulk, Template (Stored)
2000ms
5001+
Bulk, Template (Stored)
No specific target
Methods used to achieve target time
Whilst we validate key inputs to the messaging API, actual message processing and validation (as well as Spam Scoring) takes place asynchronously.
This may mean that SMS messages sent to and accepted by Connect may fail at a later date.
When stored templates are involved, they are pre-compiled and made available for each individual SMS sent. When you send a template as part of the message send process, the template is typically compiled for each individual message which results in a significant decrease in performance.
Connect is however smart enough to analyse messages within the Bulk endpoint, and will compile a single template if it is static for every message for the purpose of that bulk send.
This behaviour should not be relied on however, as successive bulk sends will still continue to recompile the message. We always recommend using and maintaining stored templates where possible.
What may affect response times vs targets
There are a number of factors that can affect response times for methods called against our API. A few are listed below:
Network Latency - Geographic location can affect response times between our environments.
Request Throttling - We apply soft request throttling on our API, meaning that you may occasionally receive a HTTP 429. Through our libraries, this will retry automatically however may result in a longer perceived response time over the case of multiple requests.
Payload Size - The size of the SMS message and/or its template may affect response times.
Once your message is accepted
After we accept your message, we perform asynchronous processing and validation which may add a further 50ms to the time it takes to relay the message to our network providers.
This processing primarily serves as an anti-spam function, which protects our business directly, and yours indirectly as a means to prevent smishing or other fraudulent activity from taking place on our systems, or those of our partners.
Periodically, random sampling of messages is performed for each customer to determine an overall "spam score" for an account. For most of our customers we expect this to be 0 especially after passing the each-message anti-spam. This process is a more comprehensive, AI analysis of messages and any links contained within and may add up to 2 seconds to delivery if you are part of the sample.
Network Delivery Performance
We are reliant on major networks in multiple countries to deliver messages successfully, and we pride ourselves on the routes that we have available to us, ensuring quality and performance for you as our customer.
However, we are not able to guarantee delivery times of messages in any way in the same way that our network partners can't.
The reason for this is that, whilst SMS is simple on the surface, it is relatively complex in practice with varying systems and parties involved.
When you send an SMS from your phone, it gets transmitted to the nearest tower to your device. That cell tower passes the message on to an SMS center which typically belongs to a specific network. The SMSC routes the message to other networks, which then deliver the message to the closest cell tower to the recipient device.
At all points in the chain, latency is involved and highly variable. If you want a real world demonstration, try to send an SMS from your phone to friends or family at midnight on new years eve.