Msg API: TechTo's Messaging API and How Messages Reach a Phone
Updated: Oct 5
By TechTo Networks · Originally published July 7, 2025 · Reviewed and updated periodically
Quick Answer
The Msg API is TechTo's messaging API — a real, documented HTTP interface (not a fictional REST API) that lets your application send DLT-compliant SMS programmatically. This page covers what the Msg API is, how to use it, and — because it's genuinely useful to understand — what happens behind the scenes between your HTTP request and a message actually arriving on someone's phone, including the conversion to the carrier-grade SMPP protocol that typically happens internally.
Table of Contents
What Is TechTo's Msg API?
Why the Msg API Is Built as an HTTP Interface
Authentication Variants: Tally, Token, and XML
Message Categories and Routes
What Happens Behind the Scenes: From HTTP to Carrier Delivery
How HTTP Messages Convert to SMPP in the Backend
Why This Architecture Benefits You as a Developer
DLT Compliance and the Msg API
Monitoring Delivery: Checking Message Status
Common Mistakes When Using the Msg API
Security Practices for the Msg API
Common Use Cases for the Msg API
Msg API Pricing
A Real Code Example
Getting Started
Msg API: Frequently Asked Questions
1. What Is TechTo's Msg API?
The Msg API is TechTo's messaging API for sending SMS programmatically from your application — triggered by a signup, an order, or any event your system already knows about, rather than requiring a person to send each message manually.
It's a real HTTP GET, query-parameter API, available in three authentication variants (Tally username/password, token-based, and XML), not a JSON REST API with Bearer-token authentication, which is a common assumption worth correcting up front. For the complete parameter reference and code samples in five languages, see TechTo's technical documentation and the HTTP API reference — this page gives a fuller orientation and then focuses on something those pages don't cover in depth: what actually happens to your message after you send it.
2. Why the Msg API Is Built as an HTTP Interface
It's worth understanding why TechTo's Msg API is a plain HTTP interface rather than, say, a WebSocket connection or a protocol requiring a persistent client library — because the reasoning explains a lot about how to use it well.
Statelessness. An HTTP GET request carries everything needed to process it in the request itself. Your application doesn't need to maintain a connection, manage a session, or handle reconnection logic — call the endpoint, get a response, move on. This matters for anything running in a serverless environment, a short-lived function, or a simple script, none of which handle a persistent connection gracefully.
No SDK required. Because the interface is just HTTP with query parameters, any language or framework with basic HTTP support can call it — there's no dependency on an official client library that might lag behind your language's current version, go unmaintained, or introduce its own bugs.
Debuggability. An HTTP GET request with query parameters is trivially inspectable — you can test it directly in a browser address bar, log it in plain text, or replay it with curl without any special tooling. A binary protocol or a complex RPC framework doesn't offer this.
The trade-off, stated honestly: an HTTP-per-message model has more per-request overhead than a persistent binary connection would at extremely high volume. This is a real trade-off, not a free lunch — it's why very high-volume senders and resellers sometimes move to a dedicated high-throughput connection instead. For the large majority of businesses, though, the simplicity wins decisively over the marginal throughput difference, which is why this is the default and recommended way to use TechTo's messaging capability.
3. Authentication Variants: Tally, Token, and XML
The Msg API offers three ways to authenticate and format your request, and picking the right one for your situation is worth a moment's thought.
Tally (Username/Password)
The simplest variant — your account credentials passed directly as query parameters:
Good for a first integration, a quick internal tool, or any situation where the simplicity of not managing a separate token outweighs the convenience of being able to rotate credentials independently from your core account login.
Token-Based
Authenticates with an account token instead of your primary username and password, and adds a templateid parameter for your DLT-approved template:
This variant also exposes delivery-report and credit-balance lookups that return JSON (covered in Section 9), and is the recommended default for most new integrations — a leaked token can be rotated without touching your account's core login credentials, which is a meaningfully better security posture than sharing your primary password across every system that sends messages.
XML
The same parameters wrapped in a URL-encoded XML payload rather than flat query parameters — useful if your existing systems (older ERPs, some enterprise middleware) already standardize on XML for outbound integrations, so the Msg API fits into that pattern without forcing a mismatched data format.
Which to choose: token-based for anything new, Tally for the simplest possible quick integration, XML if your stack already expects it. All three carry the same underlying request — the choice is about what fits your existing systems and security practices, not about one being objectively superior.
4. Message Categories and Routes
Every message sent through the Msg API falls into a category, set via the route parameter, and getting this right affects both whether your message is delivered and when:
Route | Category | Reaches DND Numbers? | Sending Window |
1 | Promotional | No | 9 AM – 9 PM |
2 | Transactional | Yes | 24/7 |
3 | Sender ID | Varies | Varies |
4 | Trans OTP (token/XML) | Yes | 24/7 |
9 | International | N/A | 24/7 |
10 | Trans2 | Yes | 24/7 |
Promotional covers marketing content and is filtered against India's DND (Do Not Disturb) registry. Transactional covers service-related content — order confirmations, alerts — and reaches DND-registered numbers around the clock. OTP traffic is typically routed separately for priority handling given how directly authentication latency affects a user's experience.
Each route requires its own DLT-registered sender ID and matching templates — a header approved for Transactional use isn't automatically valid for Promotional, and vice versa. Using the wrong route for your content type isn't just a technical mismatch; sending marketing content through a Transactional route to bypass DND filtering is a TRAI compliance violation that risks your sender ID being blocked entirely.
5. What Happens Behind the Scenes: From HTTP to Carrier Delivery
Here's the part most API documentation skips: calling the Msg API's HTTP endpoint is simple from your side, but a fair amount happens between that call and a message actually appearing on someone's phone.
Mobile carrier networks don't speak HTTP. Carriers operate their SMSCs (Short Message Service Centres) using SMPP (Short Message Peer-to-Peer) — a persistent, binary protocol built specifically for telecom-grade message exchange, which predates and is fundamentally different from web protocols like HTTP. Your application never has to know this, because the gateway infrastructure behind the Msg API handles the translation for you. But understanding that this translation happens — and roughly how — helps explain why a "simple" API call is backed by genuinely carrier-grade delivery infrastructure, not just a thin wrapper.
At a high level, the journey looks like this:
Your application sends an HTTP GET request to the Msg API.
The gateway layer validates your credentials, checks DLT compliance (sender ID registered, template approved), and checks your account's credit balance and sending limits.
The message is queued for delivery, with priority typically given to OTP and Transactional traffic over Promotional.
A persistent connection to the carrier (maintained separately from your individual request) carries the message the rest of the way using SMPP.
The carrier's SMSC attempts delivery to the handset, applying DND filtering for Promotional content.
A delivery receipt flows back through the same chain, eventually becoming available to your application via the Msg API's status-lookup call.
6. How HTTP Messages Convert to SMPP in the Backend
When your application calls the Msg API over HTTP, the request is received by gateway infrastructure that then re-submits the message to the carrier using SMPP over a persistent connection maintained specifically for that purpose. This HTTP-to-SMPP bridging is a well-established pattern across the SMS gateway industry, commonly handled by dedicated gateway software built for exactly this job.
Kannel is a widely known example of this category of software — a mature, open-source gateway application that has been used across the telecom industry for years specifically to bridge simple HTTP or SMS-center interfaces to the SMPP protocol required by carrier SMSCs. Other commercial and open-source alternatives exist (Jasmin SMS Gateway is another commonly referenced example). The general pattern these tools implement is:
Receive the HTTP request from your application (the Msg API call).
Translate the request's parameters into an SMPP submit_sm PDU (Protocol Data Unit) — the binary packet format SMPP uses to represent a message.
Submit that PDU over a persistent SMPP bind (connection) already established and maintained with the carrier's SMSC.
Receive the carrier's delivery receipt asynchronously over the same SMPP connection once the message is delivered (or fails).
Translate that receipt back into a status your application can retrieve via the Msg API's delivery-report lookup.
This bridging layer also typically handles things your application doesn't need to think about: keeping the SMPP connection alive with periodic keepalive signals, reconnecting automatically if the connection drops, and managing how many messages can be "in flight" to the carrier at once (a throughput-management concept sometimes called window size in SMPP terminology) — all invisible to you as the HTTP caller.
This description reflects common industry architecture for HTTP-to-SMPP gateways generally — confirm directly with TechTo's engineering team whether it matches their specific infrastructure, since this page describes the pattern at a conceptual level rather than asserting TechTo's exact internal implementation.
7. Why This Architecture Benefits You as a Developer
The practical upshot of this two-layer design: you get the simplicity of a plain HTTP call, while the actual message delivery runs over the same carrier-grade protocol (SMPP) that telecom operators use between themselves — maintained as persistent connections with retry logic, rather than something your application has to manage directly.
A few concrete benefits that follow from this:
You don't maintain connection state. If a carrier-side connection drops, that's the gateway's problem to detect and recover from — your application just makes its next HTTP call normally.
You don't need specialized libraries. No SMPP client library, no binary protocol parsing, no PDU construction — a standard HTTP client in any language is all you need.
Scaling is someone else's infrastructure problem. As your volume grows, the gateway's connection pool and throughput management handle it — you don't need to provision or tune SMPP connections yourself.
This is also why it's worth being skeptical of any guide (including an earlier version of this one) that tells you, as an application developer using a standard HTTP API, to build a direct SMPP connection yourself with specific binary protocol parameters. If you're using the Msg API's HTTP interface, that layer is handled for you. Building your own direct SMPP integration is a separate, much bigger undertaking — relevant only if you have a specific reason to bypass the HTTP layer entirely (extremely high volume, or building your own resale infrastructure) — and if that's genuinely your situation, that's a conversation to have directly with TechTo's technical team about a dedicated SMPP account, not something to attempt from a generic guide's description of TLV tags.
8. DLT Compliance and the Msg API
Every commercial SMS sent in India — regardless of what happens at the protocol level behind the scenes — has to clear TRAI's DLT (Distributed Ledger Technology) framework: a registered entity, an approved sender ID, and a template matching your message content exactly.
On the Msg API, you provide this through standard parameters when you make your HTTP call:
sender — your DLT-registered sender ID (header), approved for the specific category (route) you're using.
templateid (token and XML variants) — the ID of your pre-approved message template.
The sms parameter's content must match your registered template exactly, with only the genuinely variable portions (a name, an order number, an amount) differing per send.
TRAI's current framework also requires template variables to be explicitly typed (numeric, alphanumeric, URL, and other approved categories) at registration time, under a direction reported as dated 18 November 2025 — verify the exact date and current requirements against TRAI's direction or your DLT portal notice.
What happens to this compliance data as the message moves through the backend toward SMPP delivery is TechTo's infrastructure's responsibility, not something you need to manage at the HTTP layer. See the DLT and TRAI regulations resource for the full compliance picture, including entity registration and the template-approval process.
9. Monitoring Delivery: Checking Message Status
A successful Msg API call returns a numeric message ID as plain text — that confirms the gateway accepted your request, not that the message was delivered. To check actual delivery status, the token-authenticated variant exposes a lookup:
This returns delivery status as a JSON array, letting your application distinguish "delivered," "pending," and "failed" (with a reason code on failure) rather than assuming success from the initial response alone.
A practical pattern: poll this endpoint with a backoff schedule after sending — for example, a first check after 30 seconds, then at 2 minutes, then at 10 minutes — rather than checking immediately and repeatedly. Treat "no final status after your polling window" as its own state worth logging, not an assumed failure.
Monitor delivery rate by route, not just in aggregate. A dip isolated to your OTP route while Transactional and Promotional stay steady usually points to a different (and often more urgent) cause than an account-wide dip — the two deserve different diagnostics.
10. Common Mistakes When Using the Msg API
Assuming a successful API response means the message was delivered. It means the gateway accepted the request. Check delivery status separately via Section 9's lookup for anything where confirmation matters.
Letting message content drift from the registered template. A date format change, an added word, or different punctuation in how your application renders a message creates a template mismatch invisible to a human but fatal at the carrier level — the message is blocked, not delivered with a warning.
Using the wrong route for your content type. Sending Promotional content through a Transactional-registered sender ID to bypass DND filtering is a compliance violation, not a convenient workaround, and risks the sender ID being blocked entirely.
Calling the Msg API directly from a mobile app or browser. Both the Tally and token variants carry credentials in the request. Always call from your backend, never from distributed client code.
Not planning for ambiguous failures. A network timeout doesn't tell you whether the message was actually accepted. For anything where a duplicate send has a real cost (a payment confirmation, for instance), record the send attempt before calling the API and reconcile rather than blindly resending — the developer integration guide covers this pattern for production-scale sending.
Assuming personalized bulk sending works via comma-separated numbers. The number parameter's comma-separated format sends identical text to every recipient — personalized content (different name or amount per recipient) requires one call per recipient.
11. Security Practices for the Msg API
Mask credentials in logs. Because this is a GET-based API, your username, password, or token appears directly in the request URL. Make sure your logging, monitoring, and reverse proxy tools redact query strings — otherwise credentials end up sitting in plaintext logs.
Prefer the token variant for new integrations, since a leaked token can be rotated independently of your account's core login.
Store credentials in environment variables or a secrets manager, never hardcoded in source or committed to version control.
Validate phone numbers server-side before calling the Msg API — don't rely on client-side validation alone.
Rate-limit any endpoint of yours that triggers a send, particularly anything user-facing like an OTP request button, to prevent abuse that could run up your credit usage or be used to harass a third party's phone number.
12. Common Use Cases for the Msg API
Authentication and OTP. Login and transaction verification codes — the most universal use case, since SMS reaches a phone without requiring an app or internet connection.
E-commerce order lifecycle. Order confirmation, dispatch notification, delivery confirmation — typically a mix of Transactional messaging triggered automatically as an order moves through fulfillment.
Banking and fintech alerts. Transaction confirmations, balance notifications, and EMI reminders, where delivery reliability and the correct route (Transactional, not Promotional) matter directly to customer trust.
Appointment and booking reminders. Healthcare, services, and hospitality businesses commonly use the Msg API to reduce no-shows with timely reminders ahead of a scheduled appointment.
Marketing campaigns. Promotional-route messaging to an opted-in audience, respecting the DND registry and the 9 AM–9 PM sending window.
Each of these maps to a specific route and category covered in Section 4 — matching your use case to the correct route from the start avoids the most common compliance mistake new integrations make.
Logistics and delivery notifications. Dispatch alerts, out-for-delivery notices, and delivery-attempt updates — particularly valuable in areas with inconsistent mobile data connectivity, where SMS remains reliable in situations an app-based tracking experience can't guarantee.
Education. Fee-payment reminders, exam schedules, and result notifications aimed at parents who may not consistently check email or a school's app — a pattern where SMS's universal reach matters more than richer alternatives.
Internal operational alerts. Some businesses use the Msg API for internal notifications — a monitoring system alerting on-call staff, a workflow tool flagging an exception that needs human attention — treating SMS as a dependable fallback channel for anything that absolutely needs to reach someone regardless of whether they're watching a dashboard or an inbox at that moment.
13. Msg API Pricing
Rather than quote specific per-message rates here — figures that vary by route and change over time — TechTo's pricing page is the canonical, actively maintained source. When requesting a quote, ask specifically for the rate on the route you'll use most (OTP, Transactional, or Promotional), since a single "starting from" figure usually reflects the cheaper Promotional rate and won't represent your actual cost if most of your traffic is OTP or Transactional.
14. A Real Code Example
import requests
API_TOKEN = "YOUR_API_TOKEN"
BASE_URL = "https://godspeed.liveair.co.in/httpapi/tokan/"
def send_sms(sender: str, number: str, message: str, route: str = "2") -> str:
params = {
"token": API_TOKEN, "sender": sender, "number": number,
"route": route, "type": "1", "sms": message,
}
response = requests.get(BASE_URL, params=params, timeout=10)
return response.text.strip() # numeric message ID, or a documented error code
print(send_sms("TECHTO", "9198XXXXXXX0", "Your order #4821 has been confirmed."))
const axios = require("axios");
async function sendSms(sender, number, message, route = "2") {
const response = await axios.get("https://godspeed.liveair.co.in/httpapi/tokan/", {
params: { token: process.env.MSG_API_TOKEN, sender, number, route, type: "1", sms: message },
timeout: 10000,
});
return String(response.data).trim();
}
For samples in PHP, Java, and cURL, plus the complete error-code table and delivery-report lookup, see TechTo's technical documentation.
14a. Measuring Whether Your Msg API Integration Is Actually Working
Beyond the happy path of "did the call return a message ID," a few things are worth monitoring once you're sending real traffic through the Msg API:
Error-code distribution over time. A sudden rise in one specific error code points to a specific, diagnosable cause — a credential issue, a template mismatch, a low-credit route — rather than a vague "something's wrong." Treating all failures as one undifferentiated bucket makes this invisible.
Delivery rate by route, not blended. As noted in Section 9, a dip isolated to one route usually has a different cause than an account-wide dip, and the two deserve different investigation.
Time from send-call to confirmed delivery, especially for OTP traffic, since this reflects what your users actually experience — carrier and handset effects included — rather than how quickly your own code executed the HTTP request.
Credit balance trend against your sending pace, so a campaign or a sustained increase in traffic doesn't stall mid-run because nobody was watching the balance on a specific route.
Establishing your own baseline over your first few weeks of production traffic, then alerting on meaningful deviation from it, is a more reliable practice than comparing against any benchmark figure quoted in a generic guide — including earlier versions of this one.
15. Getting Started
Register your account and complete DLT registration (entity, sender ID, and your first templates) in parallel with any development work — this is typically the longer lead time, not the coding.
Choose your authentication variant (Section 3) based on your integration's needs.
Make a test send using a number your team controls, and verify actual delivery via the status lookup in Section 9, not just a successful initial response.
Build your production integration with the common mistakes in Section 10 and the security practices in Section 11 in mind.
Monitor delivery by route on an ongoing basis once you're live.
16. Msg API: Frequently Asked Questions
What is TechTo's Msg API?
TechTo's messaging API — a real HTTP GET, query-parameter interface (Tally, token, and XML variants) for sending DLT-compliant SMS programmatically.
Is the Msg API the same as TechTo's SMS API?
Yes — "Msg API" is simply a shorter name for the same HTTP-based messaging API documented on TechTo's technical reference and HTTP API page.
Does the Msg API use SMPP?
Not from your side as a developer — you call a standard HTTP endpoint. Behind the scenes, the gateway infrastructure typically converts your request to SMPP to deliver it to the carrier, using gateway software built for that purpose (see Section 6). You don't need to implement SMPP yourself to use the Msg API.
Should I build my own SMPP connection instead of using the HTTP Msg API?
For the large majority of businesses, no — the HTTP interface already delivers over carrier-grade SMPP behind the scenes without requiring you to manage a binary protocol connection yourself. A direct SMPP account is a separate, specialized option worth discussing directly with TechTo's technical team only if you have a specific high-volume or reseller use case that justifies it.
What is Kannel, and does TechTo use it?
Kannel is a well-known open-source gateway application used across the SMS industry to bridge HTTP-style interfaces to the SMPP protocol carriers require. It's referenced here as an example of the category of software used for this kind of bridging — confirm with TechTo directly whether it or a similar tool is part of their specific infrastructure.
How does DLT compliance work with the Msg API?
The same way as any TechTo HTTP API call — your sender ID and template ID are passed as request parameters and validated against your DLT registration. See Section 8.
Which authentication variant should I use?
Token-based for most new integrations, since credentials can be rotated independently of your account login. Tally for the simplest possible setup. XML if your existing systems already expect XML payloads. See Section 3.
How do I check if a message was actually delivered?
Use the token variant's delivery-report lookup (Section 9) — a successful send response only confirms the gateway accepted the request, not that the message reached the recipient.
Can I send personalized messages to many recipients in one call?
No — the comma-separated number parameter sends identical text to every recipient. Personalized content needs one call per recipient.
Where do I find the complete Msg API documentation?
TechTo's technical reference has the full parameter list, error codes, and code samples in five languages.
Comments