Transactional SMS API: How It Works, DLT Rules, and Real Code Examples
Updated: Sep 30
By TechTo Networks · Reviewed and updated periodically
Quick Answer
A transactional SMS API sends service-related messages order confirmations, payment alerts, appointment reminders that reach DND-registered numbers and can be sent 24/7, unlike Promotional SMS. This guide covers what qualifies as transactional under India's DLT framework, the real API call to send one, and the use cases and mistakes specific to this category rather than OTP or marketing messages.
Table of Contents
What Counts as Transactional SMS (and What Doesn't)
Transactional vs. Promotional vs. OTP
DLT Categorization Rules for Transactional Messages
Sending a Transactional SMS: Real API Code Examples
Common Transactional Use Cases
Transactional SMS Pricing Considerations
Delivery Status and Monitoring
Common Mistakes with Transactional SMS
Getting Started
Pre-Launch Checklist
Frequently Asked Questions
1. What Counts as Transactional SMS (and What Doesn't)
Transactional SMS covers messages tied to a service a customer already has or an action they already took — an order they placed, an appointment they booked, a payment they made. The defining test isn't the content's tone (transactional messages can still be friendly), it's whether the message serves the transaction or relationship the customer already initiated, rather than trying to start a new one.
Generally transactional: order confirmations, shipping and delivery updates, payment receipts, appointment reminders, account balance alerts, password-reset links (non-OTP), service outage notifications to existing subscribers.
Generally not transactional: discount offers, new-product announcements, festive sale campaigns, and anything trying to generate a new purchase rather than confirm or support an existing one — that's Promotional SMS, a different DLT category with different rules.
A frequent point of confusion: OTP messages are often colloquially called "transactional" because they're not marketing, but as covered on TechTo's OTP SMS API guide, OTP has its own categorization nuance (commonly Service Implicit under current DLT guidance, though practice varies by provider) that's worth checking separately rather than assuming it's identical to general transactional messaging.
2. Transactional vs. Promotional vs. OTP
Transactional | Promotional | OTP | |
Typical content | Order updates, alerts, receipts | Offers, campaigns, announcements | Login/payment verification codes |
Reaches DND numbers? | Yes | No | Yes |
Sending window | 24/7 | 9 AM – 9 PM | 24/7 |
Sender ID format | 6-character alphabetic header | Often auto-assigned numeric | Category-specific, confirm with provider |
Consent basis | Existing customer relationship | Explicit opt-in | Implied by user-initiated action |
The practical rule: if sending outside the 9 AM–9 PM window or reaching a DND-registered number matters for your message to be useful — an order confirmation at 11 PM, a payment alert to a DND-registered number — Transactional is the category to register for, not Promotional.
3. DLT Categorization Rules for Transactional Messages
Transactional templates go through the same DLT registration TechTo's other guides describe — entity registration, sender header approval, and template approval — with a few specifics for this category:
Sender header format. Transactional headers are typically a 6-character alphabetic code you choose (unlike Promotional, which is often auto-assigned numerically), registered specifically for Transactional use — a header approved for Promotional isn't automatically valid here.
Template variable typing. As with every DLT category, template variables must be typed at registration (numeric, alphanumeric, URL, and other approved types) rather than accepted as free text — relevant here because transactional messages frequently include order numbers, amounts, and dates as variables, each of which needs the correct type tag.
Content must match the registered template exactly. This applies to every category, but transactional messages are especially prone to drift because they're often assembled from multiple data fields (customer name, order ID, amount, date) in application code — a small formatting change in how a date or amount is rendered can create a mismatch with the registered template without anyone intending to change the wording.
Route selection matters for delivery, not just compliance. Using the Transactional route (rather than accidentally sending transactional content through a Promotional-registered header to save on registration steps) is what allows the message to reach DND-registered numbers and send outside the 9 AM–9 PM window — get this wrong and messages either fail outright or reach a smaller audience than intended.
4. Sending a Transactional SMS: Real API Code Examples
TechTo's SMS API is an HTTP GET, query-parameter API — not a JSON REST API — available in Tally (username/password), token-based, and XML variants. The token variant is shown below since it also supports delivery-report lookups, useful for confirming transactional messages actually reached the customer. Full parameter and error-code reference: see the HTTP API documentation.
Endpoint:
route=2 is the Transactional route. A successful call returns a numeric message ID as plain text; a response in the documented error-code range indicates a failure (invalid sender, invalid number, template mismatch, low credits, and others).
Python
import requests
API_TOKEN = "YOUR_API_TOKEN"
BASE_URL = "https://godspeed.liveair.co.in/httpapi/tokan/"
def send_transactional_sms(sender: str, number: str, message: str) -> str:
params = {
"token": API_TOKEN,
"sender": sender,
"number": number,
"route": "2", # Transactional
"type": "1", # Text
"sms": message,
}
response = requests.get(BASE_URL, params=params, timeout=10)
return response.text.strip() # message ID, or a documented error code
# Example: order confirmation
send_transactional_sms(
sender="TECHTO",
number="9198XXXXXXX0",
message="Hi Anjali, your order #48213 has been confirmed and will ship within 2 business days."
)
Node.js
const axios = require("axios");
const API_TOKEN = "YOUR_API_TOKEN";
const BASE_URL = "https://godspeed.liveair.co.in/httpapi/tokan/";
async function sendTransactionalSms(sender, number, message) {
const response = await axios.get(BASE_URL, {
params: { token: API_TOKEN, sender, number, route: "2", type: "1", sms: message },
timeout: 10000,
});
return String(response.data).trim();
}
PHP
<?php
function sendTransactionalSms(string $sender, string $number, string $message): string {
$params = [
"token" => "YOUR_API_TOKEN", "sender" => $sender, "number" => $number,
"route" => "2", "type" => "1", "sms" => $message,
];
$url = "https://godspeed.liveair.co.in/httpapi/tokan/?" . http_build_query($params);
return trim(file_get_contents($url));
}
Important: the message text above must match your DLT-registered template exactly, with only the variable portions (name, order number, in this example) coming from your application data. See Section 3 for why this matters and Section 8 for what goes wrong when it's overlooked.
For production use — queueing, retry logic, and idempotency so an ambiguous failure doesn't cause a duplicate order-confirmation send — see the developer integration guide.
5. Common Transactional Use Cases
E-commerce. Order confirmation, dispatch notification, out-for-delivery alert, delivery confirmation — a sequence of transactional touchpoints across a single order's lifecycle, each typically its own registered template.
Banking and fintech. Transaction alerts, balance notifications, EMI due reminders — high-trust content where template accuracy and delivery reliability matter more than almost any other use case, since these messages often carry financial stakes for the recipient.
Logistics. Shipment dispatched, out-for-delivery, delivery attempted/failed, delivery confirmed — frequently the highest-volume transactional use case for a business with physical fulfillment.
Healthcare. Appointment confirmations and reminders, report-ready notifications, prescription refill alerts.
Travel and hospitality. Booking confirmations, check-in reminders, itinerary changes — where the 24/7 sending window matters because a booking confirmation delayed until the next day's Promotional window would arrive too late to be useful.
SaaS and subscription services. Payment receipt, subscription renewal confirmation, usage-limit alerts — messages tied to an existing account relationship rather than a marketing push.
Government and utility services. Bill-due reminders, payment confirmations, and service-status updates to existing account holders — transactional in nature since they relate to an existing service relationship rather than soliciting new business.
Education. Fee-payment confirmations, exam-hall-ticket availability notices, and result-declaration alerts sent to students or parents with an existing enrollment — distinct from promotional admissions-campaign content, which belongs in a different category.
6. Transactional SMS Pricing Considerations
Transactional-route pricing is typically set separately from Promotional and OTP rates, reflecting the 24/7, DND-bypassing nature of the category. Rather than quote a specific figure here that will go stale, TechTo's pricing page is the canonical source — when requesting a quote, ask specifically for the Transactional rate rather than a blended "starting from" figure, since that headline number is usually the cheaper Promotional rate and won't reflect what you'll actually pay for this category.
7. Delivery Status and Monitoring
The token-authenticated API variant supports a delivery-report lookup using the message ID returned from your send call:
For transactional messages specifically, worth monitoring separately from your Promotional traffic's delivery rate, since a dip isolated to Transactional sends — while Promotional stays normal — usually points to a template or header-registration issue rather than the DND-filtering behavior you'd expect to explain a Promotional dip. Treating both routes' delivery data as one blended number can mask a transactional-specific problem for longer than it should take to notice.
8. Common Mistakes with Transactional SMS
Sending Promotional content through a Transactional header to bypass DND filtering. This is a TRAI violation, not a workaround, and risks the sender header being blocked entirely rather than just that one campaign failing.
Letting application-generated formatting drift from the registered template. A date rendered as "12/09/2026" in testing and "Sep 12, 2026" in a later code change is enough of a mismatch to fail at the carrier level, even though a human reader would consider both acceptable.
Registering one generic template and reusing it loosely across different message types. A template approved for "order confirmed" content shouldn't be stretched to also cover "order delayed" — different content requires its own registered template, even within the same broad use case.
Assuming Transactional automatically means high priority or guaranteed fast delivery. The category determines DND-reach and sending-window rules, not a specific speed guarantee — if latency is critical (a payment confirmation a user is actively waiting on), that's worth confirming with your provider rather than assuming from the category name alone.
Not separating Transactional and Promotional credit usage in monitoring, making it hard to notice if a promotional campaign is unexpectedly consuming transactional-route budget, or vice versa.
9. Getting Started
Register your Transactional sender header on a DLT-approved portal — a 6-character alphabetic code, registered specifically for this category.
Register your message templates, one per distinct message type (order confirmed, order shipped, payment received, and so on), with each variable field correctly typed.
Test the exact rendered message — including realistic variable values, not placeholder text — against your registered template before going live.
Integrate the send call using the code samples in Section 4, or the production-grade architecture in the developer integration guide if this is a high-volume, business-critical flow.
Monitor delivery by route separately from your Promotional traffic, as covered in Section 7.
10. Pre-Launch Checklist
DLT compliance:
Transactional sender header registered and approved
Each distinct message type has its own registered, approved template
Template variable types match what your application actually sends
Rendered message text tested against realistic (not placeholder) variable values
Delivery and integration:
Test sends confirmed on multiple operators
Delivery-status polling implemented for at least your highest-stakes transactional messages
Transactional delivery rate monitored separately from Promotional
Retry/idempotency logic in place for anything where a duplicate send has a real cost (see the developer integration guide)
11. Frequently Asked Questions
What's the difference between Transactional and OTP SMS? OTP is a specific, authentication-focused subset of non-marketing messaging with its own categorization nuance — see the OTP SMS API guide for that detail. General Transactional SMS covers a broader range of service-related content (order updates, alerts, receipts) beyond authentication codes specifically.
Can Transactional SMS reach DND-registered numbers?
Yes — that's one of the defining differences from Promotional SMS, which is filtered against the DND/NCPR registry.
Is there a sending-window restriction on Transactional SMS?
No — unlike Promotional SMS, which is restricted to 9 AM–9 PM, Transactional messages can be sent 24/7, which matters for time-sensitive content like delivery updates or payment alerts that can't wait for a daytime window.
Can I use the same sender ID for Transactional and Promotional messages?
No — each is registered separately per category, and a header approved for one isn't automatically valid for the other.
What happens if my transactional message doesn't exactly match the registered template?
It's blocked at the carrier level rather than delivered with a warning — this is the most common cause of unexpected transactional-message failures, often introduced by a small formatting change in how application code renders a variable field.
Do transactional messages cost more than promotional messages?
Pricing varies by provider and is typically set per route rather than being uniformly higher or lower -see TechTo's pricing page for current rates rather than assuming a fixed relationship between the two categories.
Should high-volume transactional sending use a queue-based backend rather than direct API calls?
For anything business-critical or high-volume, yes — the developer integration guide covers queueing, retry logic, and idempotency design specific to this kind of production sending.
Comments