API flexibility across SMS modem platforms is usually compared by counting features, which is the least useful approach available. What matters is whether the interface lets you do the four things every real deployment eventually needs.
This article sets out the questions worth asking about protocol support, inbound delivery, receipt granularity, rate control and authentication, and explains why documentation is the most reliable predictor of how an integration will behave in production.
Does API flexibility of SMS modem brands mean supporting HTTP, SMPP, or both?
Both is better, for operational reasons.
An HTTP interface is simpler to integrate and easier to secure with standard tooling, while a session-based interface typically offers lower per-message overhead and finer control over the submission window.
Where a platform supports only one, the choice has already been made for you, and it may not be the one your application needs. Where it supports both, the same integration can start on the simpler interface and move to the other when volume justifies it, without changing the application’s logic. That migration path is worth more than a small performance difference at the volumes most deployments actually run.
The message layer both interfaces sit on is defined in ETSI TS 123 040 and 3GPP TS 23.040, and the status semantics that both must expose are part of that specification. A platform that supports two protocols but reports status differently on each is a worse proposition than one that supports a single protocol consistently, because the reconciliation logic has to handle both.
| Question | Good answer | Why it matters |
|---|---|---|
| Protocols supported | HTTP and a session protocol | Allows migration without rewriting the application |
| Consistency of status | Same semantics on both | Keeps reconciliation logic single-path |
| Inbound delivery | Callback and query | Covers both low-latency and recovery cases |
| Rate visibility | Exposed through the interface | Lets the application pace itself |
How are inbound messages delivered?
Ideally by callback, with a query as a fallback.
A callback delivers inbound messages and receipts as they arrive, while a query interface lets a reconciliation job retrieve anything that was missed.
A platform that offers only a callback requires the endpoint to be reachable whenever the device sends, which is a dependency on your infrastructure rather than on the gateway. A platform that offers only polling makes every inbound message as late as the polling interval. Offering both lets the deployment use the callback for latency and the query for recovery, which is the arrangement most integrations settle on.
What the interface exposes for interrogation is standardised in ETSI TS 127 005 and 3GPP TS 27.005, and a platform whose query interface exposes the same information as its callback is easier to reconcile than one where the two disagree. Where they disagree, the discrepancy usually appears as duplicate or missing inbound records, and it is difficult to diagnose without the ability to compare the two sources directly.
Delivery receipt granularity
Per-message receipts, not per-batch summaries.
The interface should report the outcome of every submission individually, with an identifier that lets the application match the receipt to the message it sent.
Batch summaries look efficient and are nearly useless for operations, because they cannot answer the only question an operator asks: what happened to this message? Per-message receipts allow a dispute to be resolved from the record, and they allow a delivery ratio to be computed per destination, per SIM and per campaign. That is the difference between a platform that can support an investigation and one that can only report a total.
Receipt completeness is worth testing rather than assuming. Some networks do not generate a status report for every message, so a platform should expose the difference between “no receipt received” and “receipt reports failure”. A platform that collapses both into a single failure state makes the two indistinguishable in the record, and the distinction is exactly what an operator needs when investigating a delivery-rate change.
Rate control and queue visibility from the API
The interface should let the application see the limit and respect it.
Useful pacing requires more than a submission endpoint: it requires a way to know how much work is outstanding and whether the platform is keeping up.
Three capabilities matter. The first is a way to see queue depth or outstanding submissions, so the application can slow down before the platform discards work. The second is an explicit rejection when capacity is exceeded, rather than silent loss. The third is the ability to set a per-SIM interval or rate limit through the interface rather than only through a management screen. Together those three turn pacing from an estimate into a control.
Where those capabilities are absent, the application ends up inferring rate from delivery outcomes, which is slower and less accurate. The port and service conventions used to reach the interface are catalogued by the Internet Assigned Numbers Authority in its service name and port registry, with the assignment process described in RFC 6335; knowing what a platform exposes at the network level is the first step in integrating with it.
It is also worth asking how the platform reports a message that was accepted and never acknowledged. That case sits between success and failure, and the way a platform represents it determines whether the integration can park the message for a decision or is forced to guess. Guessing is how duplicates and silent losses are produced.
Authentication model
Per-account credentials, revocable, and usable without sharing a secret.
The authentication model determines whether access can be managed as the deployment grows, and whether a compromised credential can be withdrawn without disrupting everything else.
Three properties are worth confirming. Credentials should be per integration rather than per device, so that a single client can be revoked without disabling the platform. They should be revocable through the interface rather than by resetting the device. And the interface should support transport encryption, because credentials sent over an unencrypted channel are credentials that have been disclosed. Modern transport security is specified in RFC 8446, and a platform that cannot negotiate a current transport version should be treated as a legacy integration with a compensating network control.
Where the platform supports it, separate credentials per environment — production, staging and test — prevent the common accident in which a test job is pointed at the production estate. That separation costs nothing to configure and is difficult to add later once a single credential is embedded in several systems.
What does documentation quality tell you?
It predicts how the integration will go.
A platform with a reference, example responses and an error catalogue can be integrated against; one with a single marketing page cannot.
The signal is cheap to check and it is hard to fake. Look for whether the documentation states what happens on failure, whether it defines the identifiers that appear in responses, and whether it distinguishes between an accepted submission and a delivered message. Those three points are where integrations are usually misunderstood, and a platform that explains them has been integrated with before.
Ask for a sample response and a sample receipt rather than a description of them. An actual response shows the identifier fields, the status values and the error format, which together determine how much work the integration will take. Where a vendor cannot produce a sample response, the integration effort is unknown, and unknown effort is a procurement risk rather than a technical one.
A comparison checklist
The checklist compares platforms on the four capabilities an integration actually depends on, rather than on the features that appear in a specification. Each item is written so the answer is a document, a version or a test result, and it is intended to be completed before a trial rather than after one.
- Which protocols are supported, and is status reported consistently across them?
- Is inbound delivery available by callback, by query, or both?
- Are receipts per message, and do they distinguish no receipt from failed receipt?
- Can the application see queue depth or outstanding work, and does the platform reject rather than discard?
- Can per-SIM rate limits be set through the interface?
- Are credentials per integration, revocable, and usable over an encrypted transport?
- Does the documentation include sample responses for both submission and receipt?
The checklist produces an integration risk assessment rather than a feature comparison, which is the more useful output. Two platforms with the same feature list can differ substantially in how long the integration takes, and the difference is usually documentation and error semantics rather than capability.
Two further questions are worth adding when the deployment will be operated by more than one team. First, is the interface versioned, and how are breaking changes announced? A platform whose interface changes without notice forces the integration to be defensive against the platform rather than against the network. Second, does the platform document its own limits, such as maximum outstanding submissions or a maximum message rate per interface? Limits that are documented can be designed around, while limits that are discovered in production are incidents.
Finally, ask how the platform behaves when it is restarted while work is outstanding. Whether submissions are queued, rejected or lost determines how much state the application has to keep, and it is one of the few behaviours that cannot be inferred from the interface documentation unless the vendor has documented it deliberately. A platform that answers that question clearly has been operated at volume by somebody.
Ask for a sample response before you compare feature lists. Send your integration requirements, expected volume and environment count to service@telarvo.com, or review the published configurations on the SK-SMS Gateway range and the SMS gateway solution page. Telarvo publishes the SK-SMS gateway range, the TYH modem pools and the TGW SMS machine on its product pages, and the configurations referenced above come from those listings.
FAQ
Is a REST API always better than a session protocol?
No. A REST interface is easier to integrate and easier to secure with familiar tooling, while a session protocol typically gives finer control over the submission window at high volume. The useful position is a platform that supports both, so the integration can start simple and move later without being rewritten. Support for both is a design decision worth confirming before purchase.
What should we check first in a new API?
The error semantics. Understanding what happens when a submission is rejected, when the queue is full and when a receipt never arrives determines how much defensive logic the application needs. Feature lists rarely mention those cases and integrations are usually decided by them. Ask for the error codes and what each one means in practice. Ask for the retry guidance too, because a platform that expects application retries behaves differently from one that does not.
Why do receipts sometimes arrive without an outcome we can use?
Because some networks generate status reports selectively, and the report that arrives may indicate that the message was submitted rather than that it was delivered. Confirm what each status value means in the platform documentation, and keep the distinction between no receipt and a failed receipt in your own record. The two lead to different actions. Record which status values your integration treats as final and which it waits on, because the choice affects reconciliation.
Can we share one credential across environments?
It works until a test job is pointed at production by mistake, and then it is expensive. Separate credentials for test, staging and production cost nothing to configure at the start and are awkward to introduce later. Ask whether the platform supports per-integration credentials that can be revoked individually. Individual credentials also make the log attributable. Confirm that credentials can be rotated without downtime, since that is the step most often needed during an incident.
{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “Is a REST API always better than a session protocol?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “No. A REST interface is easier to integrate and easier to secure with familiar tooling, while a session protocol typically gives finer control over the submission window at high volume. The useful position is a platform that supports both, so the integration can start simple and move later without being rewritten. Support for both is a design decision worth confirming before purchase.”
}
},
{
“@type”: “Question”,
“name”: “What should we check first in a new API?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “The error semantics. Understanding what happens when a submission is rejected, when the queue is full and when a receipt never arrives determines how much defensive logic the application needs. Feature lists rarely mention those cases and integrations are usually decided by them. Ask for the error codes and what each one means in practice. Ask for the retry guidance too, because a platform that expects application retries behaves differently from one that does not.”
}
},
{
“@type”: “Question”,
“name”: “Why do receipts sometimes arrive without an outcome we can use?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Because some networks generate status reports selectively, and the report that arrives may indicate that the message was submitted rather than that it was delivered. Confirm what each status value means in the platform documentation, and keep the distinction between no receipt and a failed receipt in your own record. The two lead to different actions. Record which status values your integration treats as final and which it waits on, because the choice affects reconciliation.”
}
},
{
“@type”: “Question”,
“name”: “Can we share one credential across environments?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “It works until a test job is pointed at production by mistake, and then it is expensive. Separate credentials for test, staging and production cost nothing to configure at the start and are awkward to introduce later. Ask whether the platform supports per-integration credentials that can be revoked individually. Individual credentials also make the log attributable. Confirm that credentials can be rotated without downtime, since that is the step most often needed during an incident.”
}
}
]
}