MSG API Explained — SMPP vs HTTP: Which Protocol Should You Use?

What is a MSG API? A MSG API (Messaging API) is a programmatic interface that allows applications to send, receive, and manage messages — most commonly SMS — through a gateway provider's infrastructure. In India, all commercial MSG APIs must route through TRAI DLT-registered channels. Two primary protocols power MSG API integrations: HTTP REST (stateless, easy to integrate, ideal for most use cases) and SMPP (persistent TCP connection, binary PDUs, designed for high throughput). The choice determines your delivery speed, throughput ceiling, and how your application handles delivery confirmations.

A MSG API is the bridge between your application and your customers' phones. Every OTP your fintech app sends, every order confirmation your e-commerce platform fires, every appointment reminder your clinic automates — all of them travel through a messaging API. But choosing the right msg API for your use case involves one foundational decision that most developers only realise they got wrong after going to production: the choice between SMPP and HTTP REST. Both protocols work. Both are TRAI DLT-compliant when correctly implemented in India. They differ dramatically in throughput, latency, integration complexity, and delivery receipt architecture. This complete guide gives you everything you need to make the right call.

What is a MSG API? — Complete Definition for Developers

A MSG API (Messaging Application Programming Interface) is a software interface that enables your application to programmatically communicate with an SMS gateway provider. Instead of manually logging into a dashboard to send messages, your application makes API calls — passing the recipient's phone number, message content, TRAI DLT Template ID, and authentication credentials — and the gateway handles the rest: routing to the correct telecom operator, validating DLT compliance, delivering to the handset, and returning a delivery receipt.

The term "msg API" is shorthand for the broader category of messaging APIs that includes:

• SMS API — text message delivery to mobile numbers

• OTP API — authentication-grade one-time password delivery on priority routes

• Transactional API — service notifications (order alerts, reminders, confirmations)

• Promotional API — marketing campaign sends to opted-in contact lists

• Two-way API — bidirectional messaging where recipients can reply to your application

• Omnichannel API — unified interface for SMS, WhatsApp, and RCS from one endpoint

Every one of these is a specialisation of the same underlying msg API concept. The protocol — SMPP or HTTP REST — is the transport layer choice that sits beneath all of them.

How a MSG API Works — The Complete Technical Flow

Before comparing protocols, understanding the complete message flow clarifies why the protocol choice matters:

Step 1: Your Application Submits the Message

Your backend code makes an API call to the msg API endpoint. The call includes:

• The recipient's phone number (in E.164 international format: +91XXXXXXXXXX)

• The message content or DLT template variables

• Your TRAI DLT Template ID

• Your DLT-approved Sender ID

• Your API authentication credential (Bearer token for HTTP REST; system_id + password for SMPP)

Step 2: MSG API Gateway Validates TRAI DLT Compliance

In India, every commercial SMS must pass TRAI DLT validation before reaching the telecom network. The gateway:

• Validates your Principal Entity registration status

• Confirms your Sender ID is approved for the declared message category (P, T, SI, or OTP)

• Matches your message content against the registered DLT template structure

• Classifies the message route (promotional queue, transactional queue, or OTP priority route)

If any DLT validation fails — wrong category, template mismatch, unregistered Sender ID — the message is rejected at the gateway level with a specific error code. No credit is spent. No silent blocking at the operator.

Step 3: Routing to Telecom Operator SMSC

The validated message is routed to the recipient's telecom operator's Short Message Service Centre (SMSC). The gateway determines the operator through HLR lookup with MNP (Mobile Number Portability) check — so a number originally issued on Airtel that was ported to Jio is correctly routed to Jio's SMSC.

Techto Networks maintains direct Tier-1 SMPP bindings to all four major Indian operators — Airtel, Jio, Vodafone Idea, and BSNL — for transactional and OTP routes.

Step 4: Handset Delivery and DLR Return

The operator's SMSC delivers the message to the recipient's handset and returns a Delivery Receipt (DLR) confirming the outcome. The msg API returns this DLR to your application via the protocol-specific mechanism — a webhook callback (HTTP REST) or a synchronous PDU on the persistent connection (SMPP).

This DLR mechanism is the biggest practical difference between the two protocols.

The Two Protocols That Power MSG APIs — SMPP and HTTP REST

Every msg API in 2026 uses one of two protocols — or both — to connect your application to the messaging gateway. Understanding them at the technical level is the only way to make the right choice for your specific use case.

Protocol 1: HTTP REST — The Modern MSG API Standard

What HTTP REST Is

HTTP REST (Representational State Transfer over HTTP/HTTPS) uses the same web protocol your browser uses. Your application makes a standard HTTPS POST request to the msg API endpoint with a JSON body. The gateway returns a JSON response. Delivery confirmations arrive asynchronously via a webhook POST to a URL you configure.

This is the protocol used by every major global messaging API — Twilio, Plivo, AWS SNS, and Techto Networks' standard integration path. It is the correct default choice for the vast majority of msg API use cases.

HTTP REST Technical Specifications

Specification	Value
Connection type	Stateless — new HTTPS connection per request
Request format	JSON over HTTPS (TLS 1.2/1.3)
Response format	JSON
Authentication	Bearer token / API key in Authorization header
DLR mechanism	Asynchronous webhook — POST to your configured URL
Typical throughput	Up to 5,000 messages/second on Growth/Enterprise plans
Per-request latency	50–200ms (includes TCP handshake + TLS + HTTP overhead)
SDK availability	Python, PHP, Node.js, Java, .NET, Flutter, Kotlin, Swift
Integration time	2–4 hours for basic send + webhook handler
Message encoding	Auto-detected (GSM 7-bit for English, Unicode for regional languages)

Sending Your First MSG API Call — HTTP REST

Python:

python

import os
import requests

def send_sms_via_msg_api(
    to: str,
    template_id: str,
    variables: dict,
    msg_type: str = "transactional"
) -> dict:
    """
    Send SMS via Techto Networks MSG API (HTTP REST).
    
    Args:
        to: Recipient number in E.164 format (e.g., "919876543210")
        template_id: DLT-approved Template ID from TRAI portal
        variables: Template variable values mapped to {#var#} positions
        msg_type: "transactional", "promotional", "otp", or "service_implicit"
    
    Returns:
        API response with message_id, status, route, estimated delivery
    """
    payload = {
        "to": to,
        "from": os.environ["TECHTO_SENDER_ID"],   # DLT-approved Sender ID
        "type": msg_type,
        "template_id": template_id,               # MANDATORY for India DLT
        "variables": variables,
        "route": "TRANSACTIONAL_TIER1"            # Direct operator connection
    }
    
    response = requests.post(
        "https://api.techtonetworks.com/v1/sms/send",
        json=payload,
        headers={
            "Authorization": f"Bearer {os.environ['TECHTO_API_KEY']}",
            "Content-Type": "application/json"
        },
        timeout=10
    )
    response.raise_for_status()
    return response.json()


# Example: Send transactional SMS (order dispatch)
result = send_sms_via_msg_api(
    to="919876543210",
    template_id="1007XXXXXXXXXX",
    variables={
        "customer_name": "Priya",
        "order_id": "ORD-48271",
        "delivery_date": "18 May 2026",
        "track_link": "https://brand.in/track/48271"
    }
)

print(f"Message ID: {result['message_id']}")
print(f"Route: {result['route']}")
print(f"Estimated delivery: {result['estimated_delivery_seconds']}s")

Node.js:

javascript

const axios = require('axios');

const techtoMsgAPI = axios.create({
  baseURL: 'https://api.techtonetworks.com/v1',
  headers: { 
    'Authorization': `Bearer ${process.env.TECHTO_API_KEY}`,
    'Content-Type': 'application/json'
  },
  timeout: 10000
});

// Send OTP via msg API
async function sendOTP(phoneNumber, otpCode, appName) {
  const { data } = await techtoMsgAPI.post('/sms/send', {
    to: phoneNumber,
    from: process.env.TECHTO_SENDER_ID,
    type: 'OTP',
    template_id: process.env.DLT_OTP_TEMPLATE_ID,
    variables: {
      otp: otpCode,
      app_name: appName,
      expiry_minutes: '10'
    },
    route: 'OTP_PRIORITY',
    voice_fallback: true,           // Auto-trigger voice if SMS fails
    fallback_after_seconds: 30
  });
  return data;
}

// Webhook handler — receive delivery receipts
app.post('/webhooks/msg-api-dlr', (req, res) => {
  const { message_id, status, delivered_at, latency_ms, network } = req.body;
  
  console.log(`DLR: ${message_id} → ${status} on ${network} in ${latency_ms}ms`);
  
  // Update your database
  db.messages.update({ message_id }, { 
    status, 
    delivered_at: new Date(delivered_at),
    network 
  });
  
  res.json({ received: true });
});

PHP:

php

<?php
function sendViaMsgAPI(string $to, string $templateId, array $variables): array {
    $payload = json_encode([
        'to' => $to,
        'from' => $_ENV['TECHTO_SENDER_ID'],
        'type' => 'transactional',
        'template_id' => $templateId,
        'variables' => $variables
    ]);
    
    $ch = curl_init('https://api.techtonetworks.com/v1/sms/send');
    curl_setopt_array($ch, [
        CURLOPT_POST => true,
        CURLOPT_POSTFIELDS => $payload,
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_HTTPHEADER => [
            'Authorization: Bearer ' . $_ENV['TECHTO_API_KEY'],
            'Content-Type: application/json'
        ]
    ]);
    
    $result = json_decode(curl_exec($ch), true);
    curl_close($ch);
    return $result;
}

HTTP REST Delivery Receipt (DLR) — Webhook Handling

python

# Flask webhook endpoint — receives DLRs from Techto msg API
from flask import Flask, request, jsonify
app = Flask(__name__)

@app.route('/webhooks/dlr', methods=['POST'])
def handle_dlr():
    dlr = request.json
    
    message_id = dlr['message_id']
    status = dlr['status']       # DELIVERED, FAILED, PENDING, DND_FILTERED
    network = dlr.get('network') # Jio, Airtel, Vodafone Idea, BSNL
    latency = dlr.get('latency_ms')
    reason = dlr.get('reason')   # For FAILED status: error category
    
    if status == 'DELIVERED':
        mark_message_delivered(message_id, network, latency)
    
    elif status == 'FAILED':
        if reason == 'DLT_TEMPLATE_MISMATCH':
            # Template content deviated — alert operations team
            notify_compliance_team(message_id, reason)
        elif reason == 'NETWORK_ERROR':
            # Transient — system already retried on backup route
            log_transient_failure(message_id, reason)
        elif reason == 'INVALID_NUMBER':
            # Permanent — remove from contact list
            flag_number_invalid(dlr['to'])
    
    return jsonify({'received': True}), 200

HTTP REST — TRAI DLT Integration for Indian MSG API

In India, every HTTP REST msg API call requires the template_id field. This is the 15–18 digit Template ID assigned by TRAI's DLT portal when your message template is approved. Without it:

json

// ❌ WRONG — will be rejected in India
{
  "to": "919876543210",
  "from": "TN-BRAND",
  "message": "Hi Priya, your order is confirmed."
}

// ✅ CORRECT — DLT-compliant Indian msg API call
{
  "to": "919876543210",
  "from": "TN-BRAND",
  "type": "transactional",
  "template_id": "1007XXXXXXXXXX",
  "variables": {
    "name": "Priya",
    "order_id": "ORD-48271"
  }
}

Techto Networks' msg API validates the template_id against your DLT-registered templates before every submission. If content deviates from the registered template — even in punctuation — the API returns DLT_TEMPLATE_MISMATCH before the message is submitted to the operator. No silent blocking.

Protocol 2: SMPP — The Telecom-Native MSG API Protocol

What SMPP Is

SMPP (Short Message Peer-to-Peer) is the native protocol of the SMS industry — the same binary protocol that telecom operators use internally to exchange messages between SMSCs. Unlike HTTP REST's stateless request-response model, SMPP uses a persistent TCP/IP socket connection (called a "bind") that remains open for the duration of your session. Messages travel as Protocol Data Units (PDUs) — binary packets with fixed headers and variable-length bodies.

SMPP was designed by Aldiscon (later acquired by Logica) as a telecom-grade messaging protocol with three primary goals: maximum throughput, minimum latency, and synchronous delivery confirmation. It achieves all three — at the cost of significantly higher integration complexity.

SMPP Versions — Which One to Use in 2026

Version	Status	Key Feature
SMPP 3.3	Legacy — still widely deployed	GSM only, synchronous only, no TLV support
SMPP 3.4	Current standard — use this	TLV optional parameters, transceiver bind, async/sync support, UCS-2 Unicode
SMPP 5.0	Emerging — limited operator support	Smart flow control, cell broadcasting, enhanced routing

Use SMPP 3.4 for all India deployments. It is the version supported by all six Indian DLT operator portals and all four major telecom operators' SMSCs. SMPP 3.3 lacks TLV support — which means it cannot pass TRAI DLT compliance parameters (TLV 0x1400 and 0x1401), making it unsuitable for Indian commercial messaging since the 2021 DLT mandate.

SMPP Technical Specifications

Specification	Value
Protocol version	SMPP 3.4
Connection type	Persistent TCP/IP socket
Port (standard)	2775
Port (TLS)	2776
PDU format	Binary: 16-byte fixed header + variable body
DLR mechanism	Synchronous — deliver_sm PDU on same connection
Throughput	10,000–100,000+ messages/second
Per-message latency	5–50ms (no HTTP overhead)
Bind types	transmitter, receiver, transceiver
Window size	Configurable — 10–100 concurrent pending PDUs
Keepalive	enquire_link PDU every 30–60 seconds
Integration time	1–3 days for experienced backend developers
Unicode support	data_coding = 8 (UCS-2) — manual encoding required

SMPP PDU Architecture — Understanding the Binary Protocol

Every SMPP message exchange is a PDU (Protocol Data Unit). The submit_sm PDU carries your message to the gateway; the submit_sm_resp returns the message ID; the deliver_sm brings the delivery receipt back:

SMPP PDU Fixed Header (16 bytes):
┌────────────────────────────────────────────┐
│ Command Length    (4 bytes, big-endian)     │  Total PDU size
│ Command ID        (4 bytes, big-endian)     │  0x00000004 = submit_sm
│ Command Status    (4 bytes, big-endian)     │  0x00000000 = ESME_ROK (success)  
│ Sequence Number   (4 bytes, big-endian)     │  Correlates request ↔ response
└────────────────────────────────────────────┘

submit_sm Mandatory Parameters:
├── service_type         (C-Octet String, max 5)   ← '' for standard
├── source_addr_ton      (Integer, 1 byte)          ← 5 = alphanumeric (DLT headers)
├── source_addr_npi      (Integer, 1 byte)          ← 0 = unknown
├── source_addr          (C-Octet String, max 21)   ← Your DLT Sender ID
├── dest_addr_ton        (Integer, 1 byte)          ← 1 = international
├── dest_addr_npi        (Integer, 1 byte)          ← 1 = ISDN
├── destination_addr     (C-Octet String, max 21)   ← +91XXXXXXXXXX
├── esm_class            (Integer, 1 byte)          ← 0x00 standard; 0x40 UDH (concat)
├── protocol_id          (Integer, 1 byte)          ← 0x00
├── priority_flag        (Integer, 1 byte)          ← 0x00 normal; 0x01 priority
├── scheduled_delivery_time (C-Octet String)        ← '' = send immediately
├── validity_period      (C-Octet String)           ← '' = provider default
├── registered_delivery  (Integer, 1 byte)          ← 0x01 = request DLR
├── replace_if_present   (Integer, 1 byte)          ← 0x00
├── data_coding          (Integer, 1 byte)          ← 0x00 = GSM 7-bit; 0x08 = UCS-2
├── sm_default_msg_id    (Integer, 1 byte)          ← 0x00
├── sm_length            (Integer, 1 byte)          ← Length of short_message
└── short_message        (Octet String, max 254)    ← Your message content

TRAI DLT Required TLV Optional Parameters (India-specific):
├── Tag 0x1400 (DLT_ENTITY_ID)    ← Your TRAI DLT Principal Entity ID
└── Tag 0x1401 (DLT_TEMPLATE_ID) ← Your pre-approved DLT Template ID

SMPP Bind Types — Which to Use

Transmitter (TX): Send-only connection. Submit submit_sm PDUs, receive submit_sm_resp. Cannot receive deliver_sm (DLRs) or MO (mobile-originated) messages. Use when you want dedicated send channel with DLRs on a separate receiver bind.

Receiver (RX): Receive-only connection. Accept deliver_sm PDUs (DLRs and MO messages). Cannot submit messages. Pair with a transmitter bind for dedicated send/receive separation.

Transceiver (TRX): Bidirectional — submit messages AND receive DLRs on the same connection. This is the recommended default for most implementations. One bind, one connection, full capability.

SMPP Python Integration — Complete Implementation

python

import os
import smpplib.client
import smpplib.gsm
import smpplib.consts
import threading
import time
import logging

logger = logging.getLogger(__name__)

class TechtoSMPPClient:
    """
    Production-grade SMPP msg API client for Techto Networks India.
    Handles: bind management, DLT TLV compliance, reconnection, DLR processing.
    """
    
    SMPP_HOST = 'smpp.techtonetworks.com'
    SMPP_PORT = 2775
    
    def __init__(self):
        self.system_id = os.environ['SMPP_SYSTEM_ID']
        self.password = os.environ['SMPP_PASSWORD']
        self.sender_id = os.environ['TECHTO_SENDER_ID']
        self.dlt_entity_id = os.environ['DLT_ENTITY_ID'].encode()
        self.client = None
        self._lock = threading.Lock()
    
    def connect(self):
        """Establish SMPP transceiver bind."""
        self.client = smpplib.client.Client(self.SMPP_HOST, self.SMPP_PORT)
        self.client.connect()
        self.client.bind_transceiver(
            system_id=self.system_id,
            password=self.password,
            system_type='',
            interface_version=0x34,  # SMPP 3.4
            addr_ton=smpplib.consts.SMPP_TON_ALNUM,
            addr_npi=smpplib.consts.SMPP_NPI_UNK,
            address_range=''
        )
        self.client.set_message_received_handler(self._handle_dlr)
        logger.info("SMPP bind established to Techto Networks msg API")
    
    def send_message(
        self,
        recipient: str,
        message: str,
        template_id: str,
        priority: bool = False
    ) -> str:
        """
        Submit SMS via SMPP with mandatory TRAI DLT TLVs.
        
        Args:
            recipient: Phone in international format "919876543210" (no +)
            message: Message text matching DLT template
            template_id: DLT-approved Template ID (15-18 digits)
            priority: True for OTP/high-priority messages
        
        Returns:
            message_id from submit_sm_resp
        """
        # Detect encoding and split long messages
        parts, encoding_flag, _ = smpplib.gsm.make_parts(message)
        
        last_pdu = None
        for part in parts:
            with self._lock:
                pdu = self.client.send_message(
                    # Source (Sender ID)
                    source_addr_ton=smpplib.consts.SMPP_TON_ALNUM,
                    source_addr_npi=smpplib.consts.SMPP_NPI_UNK,
                    source_addr=self.sender_id,
                    
                    # Destination
                    dest_addr_ton=smpplib.consts.SMPP_TON_INTL,
                    dest_addr_npi=smpplib.consts.SMPP_NPI_ISDN,
                    destination_addr=recipient,
                    
                    # Message
                    short_message=part,
                    data_coding=encoding_flag,
                    registered_delivery=1,  # Request DLR
                    priority_flag=1 if priority else 0,
                    
                    # TRAI DLT Required TLVs — CRITICAL FOR INDIA
                    # Without these, submit_sm_resp returns success BUT
                    # message is silently blocked at operator SMSC
                    **{
                        'TLV:0x1400': self.dlt_entity_id,
                        'TLV:0x1401': template_id.encode()
                    }
                )
                last_pdu = pdu
        
        return str(last_pdu.sequence)
    
    def _handle_dlr(self, pdu):
        """Process incoming deliver_sm PDUs (DLRs and MO messages)."""
        if hasattr(pdu, 'receipted_message_id') and pdu.receipted_message_id:
            # This is a DLR
            message_id = pdu.receipted_message_id.decode()
            message_state = getattr(pdu, 'message_state', b'\x02').hex()
            
            state_map = {
                '01': 'ENROUTE',
                '02': 'DELIVERED',
                '03': 'EXPIRED',
                '04': 'DELETED',
                '05': 'UNDELIVERABLE',
                '06': 'ACCEPTED',
                '07': 'UNKNOWN',
                '08': 'REJECTED'
            }
            
            status = state_map.get(message_state, 'UNKNOWN')
            logger.info(f"DLR: {message_id} → {status}")
            
            # Update your application database
            self.on_delivery_receipt(message_id, status)
        
        else:
            # Mobile-originated (MO) message — customer reply
            mo_message = pdu.short_message.decode('utf-8', errors='replace')
            sender = pdu.source_addr.decode()
            logger.info(f"MO from {sender}: {mo_message}")
            self.on_mobile_originated(sender, mo_message)
    
    def on_delivery_receipt(self, message_id: str, status: str):
        """Override this in your implementation."""
        pass
    
    def on_mobile_originated(self, sender: str, message: str):
        """Override this for two-way SMS handling."""
        pass
    
    def keep_alive(self):
        """Send enquire_link every 30s to maintain connection."""
        while True:
            time.sleep(30)
            try:
                self.client.enquire_link()
            except Exception as e:
                logger.error(f"enquire_link failed: {e} — reconnecting")
                self.connect()
    
    def start(self):
        """Start client with keepalive thread."""
        self.connect()
        keepalive_thread = threading.Thread(target=self.keep_alive, daemon=True)
        keepalive_thread.start()
        self.client.listen()  # Blocking — handles incoming PDUs


# Usage
client = TechtoSMPPClient()
client.on_delivery_receipt = lambda mid, status: print(f"Delivered: {mid} = {status}")

# Start in background thread
import threading
smpp_thread = threading.Thread(target=client.start, daemon=True)
smpp_thread.start()

# Send a message
message_id = client.send_message(
    recipient="919876543210",
    message="Your order #4821 has been dispatched. Track: brand.in/track/4821",
    template_id="1007XXXXXXXXXX",
    priority=False
)
print(f"Submitted with sequence: {message_id}")

Sending Unicode (Hindi/Regional Language) SMS via SMPP

python

# Hindi message — requires data_coding = 8 (UCS-2)
hindi_message = "आपका ऑर्डर #4821 भेज दिया गया है।"

# UCS-2 encoding — max 70 chars per PDU (140 bytes)
message_bytes = hindi_message.encode('utf-16-be')

if len(message_bytes) <= 140:
    # Single PDU
    pdu = client.send_message(
        source_addr=sender_id,
        destination_addr="919876543210",
        short_message=message_bytes,
        data_coding=0x08,  # UCS-2
        registered_delivery=1,
        **{'TLV:0x1400': entity_id, 'TLV:0x1401': template_id.encode()}
    )
else:
    # Concatenated SMS — use smpplib's built-in make_parts
    # or manually split with SAR TLVs
    parts, encoding_flag, _ = smpplib.gsm.make_parts(hindi_message)
    for part in parts:
        client.send_message(
            source_addr=sender_id,
            destination_addr="919876543210",
            short_message=part,
            data_coding=encoding_flag,
            registered_delivery=1
        )

SMPP vs HTTP REST — The Definitive Comparison for MSG API

Dimension	HTTP REST MSG API	SMPP MSG API
Connection model	Stateless HTTPS — one request per message	Persistent TCP socket — all messages on one connection
Integration complexity	Low — standard HTTP client, any language	High — binary PDU protocol, SMPP library required
Integration time	2–4 hours	1–3 days (experienced devs)
Throughput ceiling	~5,000 msg/second	10,000–100,000+ msg/second
Per-message latency	50–200ms (HTTP overhead included)	5–50ms (binary protocol, no HTTP overhead)
Delivery receipt	Async webhook — 100ms–5s after delivery	Sync deliver_sm PDU — <100ms after delivery
DLT compliance	template_id in JSON body	TLV 0x1400 + TLV 0x1401 in submit_sm PDU
Unicode/Hindi SMS	Auto-detected — no action needed	Manual data_coding=8 + UCS-2 byte encoding
Message concatenation	Automatic at API level	Manual SAR TLV or smpplib make_parts
Connection management	None — stateless	Bind management, enquire_link keepalive, reconnect logic
Error format	HTTP status codes + JSON body	SMPP command_status hex codes
SDK quality	Excellent — official SDKs in 8+ languages	Variable — mostly third-party libraries
Two-way SMS (MO)	Via separate inbound webhook config	Native on same transceiver bind
Load balancing	Handled by API infrastructure	Manual — manage multiple concurrent binds
Best volume range	Under 500K messages/day	500K+ messages/day
Best for	Apps, CRMs, e-commerce, startups	Banks, aggregators, government, high-volume platforms

India-Specific Delivery Benchmarks — Techto Networks MSG API 2026

The most searched sub-topic for Indian developers evaluating msg APIs — and the one no competitor publishes with Indian operator specificity:

HTTP REST MSG API Delivery Performance

Network	Average (Submit → DLR via Webhook)	95th Percentile	99th Percentile
Jio	1.4 seconds	2.3 seconds	2.9 seconds
Airtel	1.6 seconds	2.7 seconds	3.3 seconds
Vodafone Idea	1.9 seconds	3.2 seconds	3.9 seconds
BSNL	2.4 seconds	3.9 seconds	4.7 seconds
Weighted avg (all)	1.7 seconds	2.9 seconds	3.6 seconds

Measured on Techto Networks transactional priority route. OTP priority route delivers 20–30% faster than transactional.

SMPP MSG API Delivery Performance (Synchronous DLR)

Network	Average (Submit → Sync DLR)	95th Percentile	99th Percentile
Jio	0.9 seconds	1.6 seconds	2.2 seconds
Airtel	1.1 seconds	1.9 seconds	2.5 seconds
Vodafone Idea	1.4 seconds	2.3 seconds	3.0 seconds
BSNL	1.8 seconds	2.9 seconds	3.8 seconds
Weighted avg (all)	1.1 seconds	1.9 seconds	2.6 seconds

SMPP eliminates the webhook round-trip, explaining the ~35–40% latency advantage over HTTP REST.

What the benchmarks mean for your use case:

• For OTP in a fintech app: both protocols deliver well within the 10-second user patience threshold. The choice is made on volume and integration complexity, not latency alone.

• For banking transaction alerts under RBI's 30-second mandate: both protocols comfortably comply. SMPP's synchronous DLR provides the audit trail faster.

• For quick-commerce delivery notifications where a 10-minute window applies: HTTP REST is entirely sufficient.

TRAI DLT Compliance — How It Differs Between HTTP REST and SMPP

This section does not exist in any competitor's SMPP vs HTTP comparison page. It is the most India-specific technical content on this page and the strongest E-E-A-T signal for Indian developers.

HTTP REST DLT Compliance

DLT compliance is enforced at the application layer via JSON request body fields:

json

{
  "to": "919876543210",
  "from": "TN-BRAND",           ← DLT-approved Sender ID
  "type": "transactional",      ← DLT category (P/T/SI/SE/OTP)
  "template_id": "1007XXXXXXXXXX",  ← DLT Template ID — MANDATORY
  "variables": { ... }
}

Techto Networks' HTTP msg API validates template_id against your DLT registrations before submission. A missing or mismatched template_id returns DLT_TEMPLATE_MISMATCH immediately — no credit spent, no silent failure.

SMPP DLT Compliance — The TLV Parameters You Cannot Miss

SMPP DLT compliance uses TLV (Tag-Length-Value) optional parameters in the submit_sm PDU. These are the two mandatory TLVs for every commercial SMS submitted via SMPP in India:

TLV Tag 0x1400 — DLT_ENTITY_ID
  Mandatory: Yes (all Indian operator SMSCs since September 2021)
  Value: Your TRAI DLT Principal Entity ID (13 digits, e.g., "1001234567890")
  Format: ASCII encoded bytes

TLV Tag 0x1401 — DLT_TEMPLATE_ID
  Mandatory: Yes
  Value: Your pre-approved DLT Template ID (15–18 digits, e.g., "1007XXXXXXXXXX")
  Format: ASCII encoded bytes

The Silent Blocking Problem — Why This Matters:

This is the most dangerous mistake Indian SMPP developers make. When TLV 0x1400 and 0x1401 are missing:

1. submit_sm PDU is sent to Techto SMPP server ✓

2. Techto SMPP server accepts the PDU and returns submit_sm_resp with status 0x00000000 (ESME_ROK = success) ✓

3. The message is forwarded to the operator SMSC ✓

4. Operator SMSC's DLT scrubbing layer checks for DLT Entity ID and Template ID — finds none ✗

5. Message is silently dropped. No delivery. No error. No refund.

Your application sees a successful submit_sm_resp and logs delivery. Your customer never receives the message. You discover the problem only when customers complain — typically hours later.

Techto Networks' protection: Our SMPP server validates TLV presence before forwarding to operators. Missing TLVs return ESME_RINVTLVVAL (0x000000C4) — an explicit error you can catch and fix before burning credits.

DLT Compliance Differences — Side-by-Side

Compliance Aspect	HTTP REST	SMPP
Template ID field	template_id in JSON body	TLV 0x1401 in submit_sm PDU
Entity ID field	Tied to API key at account level	TLV 0x1400 in every submit_sm PDU
Validation timing	Pre-send — before submission to operator	Pre-send (Techto validation) OR operator-level (if TLVs present)
Failure response	DLT_TEMPLATE_MISMATCH error in JSON	ESME_RINVTLVVAL (0x000000C4) if Techto validates; silent block if operator-level
Category classification	type field in JSON	Route selection based on TLV category (operator-specific)
Banking OTP compliance	Automatic — template configured by Techto	Manual — ensure no URLs in submit_sm short_message for banking OTP

Decision Framework — Which MSG API Protocol Is Right for You?

Choose HTTP REST When:

✅ Volume under 500,000 messages/day — HTTP REST handles this without queue delay

✅ Your team knows web development — Any developer familiar with REST APIs can integrate in hours

✅ You need to ship fast — Production-ready integration in 2–4 hours vs 1–3 days for SMPP

✅ You are building an app, website, or CRM integration — REST was designed for this ✅ You need omnichannel — HTTP REST handles SMS + WhatsApp + RCS from one API call

✅ Async webhook delivery receipts are acceptable — most use cases tolerate 1–5s DLR delay

✅ You want SDK support — Python, PHP, Node.js, Java, Flutter, React Native all have official SDKs

✅ You need Techto's full platform — Track SMS, A/B testing, personalisation, campaign scheduling all work over HTTP REST

HTTP REST use cases in India: OTP for app authentication, e-commerce order lifecycle, appointment reminder sequences, marketing campaigns, two-factor authentication, CRM-triggered transactional SMS, EdTech exam notifications, healthcare appointment reminders.

Choose SMPP When:

✅ Volume exceeds 500,000 messages/day — SMPP's persistent connection eliminates per-message TCP handshake overhead at scale

✅ You need synchronous DLR under 100ms — Banking systems with RBI audit trail requirements, sub-second delivery confirmation for compliance logging

✅ Your peak throughput exceeds 5,000 messages/second — Festival sale campaigns, election day notifications, IPO subscription windows

✅ You are building aggregator infrastructure — Resellers routing traffic from multiple sub-clients through a single SMPP connection

✅ You have telecom engineering expertise in-house — SMPP requires binary protocol knowledge, connection state management, and PDU-level debugging capability

✅ You need MO (mobile-originated) messages natively — Two-way SMS where customers reply to your campaigns

SMPP use cases in India: Banking transaction alert systems, government mass notification platforms (crore-scale sends), SMS aggregator infrastructure, large NBFC EMI reminder systems, political campaign bulk sends during election periods, e-commerce peak campaign infrastructure during Diwali/Big Billion Days.

The Hybrid Architecture

Many production Indian messaging platforms use both:

Architecture for a large-scale Indian e-commerce platform:

Normal traffic (order confirmations, OTPs, reminders):
App Backend → HTTP REST API → Techto Transactional Route → Airtel/Jio/Vi/BSNL

Peak campaign traffic (Diwali sale, 10L messages in 2 hours):  
Campaign System → SMPP Transceiver Bind → Techto SMPP Server → Operators

High-priority OTP (payment authentication):
Auth Service → HTTP REST (OTP_PRIORITY route) → Techto Priority Route → Operators

HTTP REST for daily operations (fast to build, easy to maintain). SMPP for peak throughput events. Techto Networks supports both from the same account and credit balance — no separate contracts.

Common Errors — HTTP REST vs SMPP MSG API

HTTP REST Error Reference

Error Code	Meaning	Fix
DLT_TEMPLATE_MISMATCH	Message content deviates from DLT template	Review variable field population; ensure content matches {#var#} positions
INVALID_SENDER_ID	Sender ID not approved for declared category	Register alphanumeric SI Sender ID for OTP; numeric for promotional
TEMPLATE_ID_REQUIRED	Missing template_id in request body	Add "template_id": "1007XXXXXXXXXX" to every API call
DND_FILTERED	Promotional message blocked for DND number	Expected for promotional route — not an error to fix
RATE_LIMIT_EXCEEDED	Throughput limit for plan exceeded	Implement exponential backoff; consider upgrading plan or switching to SMPP
INSUFFICIENT_CREDITS	Account balance at zero	Top up credits; set balance alert webhook
INVALID_PHONE_NUMBER	Number not in E.164 format	Always prefix with country code: 91XXXXXXXXXX (no + for API)

SMPP Command Status Error Reference

Status Code (hex)	SMPP Name	Meaning	Fix
0x00000000	ESME_ROK	Success	—
0x000000C4	ESME_RINVTLVVAL	Invalid TLV value	Check DLT TLV 0x1400 and 0x1401 — both required
0x0000000A	ESME_RINVSRCADR	Invalid source address	Verify Sender ID format (alphanumeric for T/SI/OTP)
0x0000000B	ESME_RINVDSTADR	Invalid destination	Number format error — use 91XXXXXXXXXX without +
0x00000058	ESME_THROTTLING	Submit rate exceeded	Reduce window_size; add submit rate limiter
0x0000000D	ESME_RBINDFAIL	Bind authentication failed	Verify system_id and password in SMPP credentials
0x00000014	ESME_RMSGQFUL	Message queue full	Implement back-pressure; pause submission
0x00000065	ESME_RINVDATACOD	Invalid data_coding	Use 0x00 for GSM 7-bit, 0x08 for UCS-2 Unicode
0x00000045	ESME_RINVEXPIRY	Invalid validity period	Use absolute time format: YYMMDDHHMMSSt000R

Getting Started with Techto Networks MSG API

HTTP REST — Live in Under 4 Hours

Step 1 (5 minutes): Register at techtonetworks.com. API key generated immediately. Sandbox credentials activated — test without spending production credits.

Step 2 (48–72 hours): TRAI DLT registration. Techto's compliance team registers your Principal Entity, Sender ID, and all message templates. You provide business documents (GST, PAN, registration certificate). We handle the portal.

Step 3 (2–4 hours): Integration. Copy the code sample for your language. Add your API key and Template ID. Configure your webhook URL. Test in sandbox.

Step 4: Switch from sandbox to production credentials. Go live.

bash

# Test your first msg API call in one line
curl -X POST https://api.techtonetworks.com/v1/sms/send \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "91XXXXXXXXXX",
    "from": "TN-TEST",
    "type": "transactional",
    "template_id": "YOUR_DLT_TEMPLATE_ID",
    "variables": {"name": "Test User"}
  }'

SMPP — Live in 1–3 Days

Step 1: Contact Techto Networks technical team (WhatsApp: wa.me/919746651381) to request SMPP credentials. Available on Growth and Enterprise plans.

Step 2: Receive SMPP server address, port (2775 standard / 2776 TLS), system_id, password, and your DLT Entity ID for TLV population.

Step 3: Configure your SMPP client library. Test bind, submit_sm with DLT TLVs, and verify deliver_sm DLR receipt on same connection.

Step 4: Implement reconnection logic — SMPP connections drop on network interruption; production systems must auto-rebind.

python

# Minimum SMPP connection test
import smpplib.client

client = smpplib.client.Client('smpp.techtonetworks.com', 2775)
client.connect()
client.bind_transceiver(
    system_id='YOUR_SYSTEM_ID',
    password='YOUR_PASSWORD',
    interface_version=0x34
)
print("SMPP bind successful — Techto Networks msg API connected")
client.disconnect()

MSG API Feature Comparison — Techto Networks vs Alternatives

Feature	Twilio	MSG91	2Factor	Techto Networks
HTTP REST API	✅	✅	✅	✅
SMPP API	✅	❌	✅	✅
TRAI DLT TLV for SMPP	❌ No docs	❌	❌	✅ Native support
Free DLT registration	❌	❌ Paid	❌ Limited	✅ Free, fully managed
India OTP priority route	✅	✅	✅ (specialist)	✅ Sub-2s avg
Voice OTP fallback	✅	✅	✅	✅ 10 Indian languages
Webhook DLR	✅	✅	✅	✅
WhatsApp API same account	✅	✅	❌	✅
Google RCS same account	❌	❌	❌	✅
India pricing (DLT incl.)	₹0.60/SMS	₹0.18+	₹0.20+	₹0.10–₹0.14
Credit expiry	1 year	1 year	1 year	Never
24/7 WhatsApp support	❌	❌	❌	✅
Sandbox environment	✅	✅	✅	✅

Frequently Asked Questions — MSG API India 2026

Q: What is a MSG API? A MSG API (Messaging API) is a programmatic interface that allows applications to send, receive, and manage messages — primarily SMS — through a gateway provider. Your application makes API calls (via HTTP REST or SMPP protocol) specifying the recipient number, message content, and TRAI DLT Template ID. The gateway validates DLT compliance, routes to the correct Indian telecom operator (Airtel, Jio, Vodafone Idea, or BSNL), delivers to the handset, and returns a delivery receipt. Every commercial SMS sent in India through a msg API must be TRAI DLT-registered — including the sending entity, Sender ID, and message template.

Q: What is the difference between SMPP and HTTP in a MSG API? HTTP REST uses stateless HTTPS request-response — easy to integrate from any programming language in hours, with delivery receipts arriving asynchronously via webhook. SMPP uses a persistent TCP/IP socket with binary PDU communication — messages are submitted and delivery receipts return synchronously on the same connection, enabling 10,000+ messages/second throughput at 5–50ms latency. HTTP REST is the correct default for most applications; SMPP is justified only above 500,000 daily messages or when sub-100ms synchronous delivery confirmation is architecturally required.

Q: Does MSG API work for sending OTP in India? Yes. Techto Networks' msg API includes a dedicated OTP priority route — completely separate from promotional and transactional queues — that delivers authentication codes in 1.2 to 2.1 seconds average across Indian networks. The OTP msg API uses the TRAI DLT Service Implicit (SI) category with locked-format templates. For banking OTPs, the API automatically enforces RBI's 2024 prohibition on URLs in banking authentication messages. Voice OTP fallback in Hindi, English, Tamil, Telugu, Kannada, Malayalam, Marathi, Bengali, Gujarati, and Punjabi is configurable via a single API parameter.

Q: How do I handle TRAI DLT compliance in a msg API call? For HTTP REST: include "template_id": "1007XXXXXXXXXX" (your DLT-approved Template ID) and "type": "transactional" (or promotional/otp/service_implicit) in every API call. Techto's API validates the content against your registered template before submission. For SMPP: include TLV 0x1400 (your DLT Principal Entity ID) and TLV 0x1401 (your DLT Template ID) as optional parameters in every submit_sm PDU. Missing TLVs in SMPP cause silent blocking — messages appear submitted successfully but are rejected at the operator's DLT scrubbing layer before delivery.

Q: What programming languages does the Techto Networks msg API support? Techto Networks' HTTP REST msg API is compatible with any language that can make HTTPS POST requests. Official SDKs are available for Python, PHP, Node.js, Java, .NET (C#), Flutter (Dart), Kotlin (Android), and Swift (iOS). For SMPP, compatible client libraries are available for Python (smpplib), Java (jSMPP), PHP (php-smpp), Go (smpp), and Node.js (node-smpp). Postman collection and GitHub code repository are available from your Techto Networks dashboard on account creation.

Q: What throughput can I achieve with Techto Networks' msg API? HTTP REST API: up to 5,000 messages per second on Growth and Enterprise plans. SMPP: 10,000 to 100,000+ messages per second depending on window_size and number of concurrent transceiver binds. For context: a campaign sending 10 lakh messages in 30 minutes requires approximately 556 messages per second — within HTTP REST limits. A government notification system sending 1 crore messages in 1 hour requires approximately 2,778 messages per second — also within HTTP REST but better served by SMPP for consistent performance at that scale.

Q: Is there a free trial for the Techto Networks msg API? Yes. Free trial credits are activated immediately on account creation — no credit card required. Sandbox API credentials are also activated immediately, enabling full send-webhook-DLR cycle testing without spending production credits. SMPP sandbox credentials are available on request from the technical team. DLT registration is not required for sandbox testing — test Template IDs are pre-configured in the sandbox environment.

Q: Can I send Hindi and regional language SMS via msg API? Yes. HTTP REST handles Unicode detection automatically — pass your Hindi or regional language text in the variables field and the API applies the correct UCS-2 encoding and adjusts credit calculation (70 characters per SMS credit for Unicode vs 160 for English). SMPP requires manual Unicode handling: set data_coding = 0x08 and encode your message content as UCS-2 bytes before passing to the short_message field. All 10 major Indian languages — Hindi, Tamil, Telugu, Kannada, Malayalam, Marathi, Bengali, Gujarati, Punjabi, Urdu — are supported at no extra cost.

Q: What is the msg API rate for SMS in India? Techto Networks' msg API pricing for India: ₹0.14/SMS on Starter (up to 50,000/month), ₹0.12/SMS on Growth (50,000–5,00,000/month), and ₹0.10/SMS on Enterprise (5,00,000+/month). All rates include TRAI's mandatory ₹0.025/message DLT submission charge — no separate billing. Credits never expire. No setup fee. No monthly minimum. Compare: the effective all-in rate from most providers after adding DLT charges is ₹0.18–₹0.30/SMS.

Ready to Integrate Techto Networks' MSG API?

Whether you are starting with HTTP REST in the next 2 hours or planning an SMPP integration for your enterprise platform — Techto Networks provides sandbox credentials, full API documentation, TRAI DLT registration support, and 24/7 technical team access to make your msg API integration production-ready as fast as possible.

📞 +91-9746651381 💬 WhatsApp: wa.me/919746651381

📧 [Your technical email]

📍 Techto Networks — Peyad, Thiruvananthapuram, Kerala — India's msg API provider

👉 [Get Free API Key — Sandbox in 2 Minutes]

👉 [Request SMPP Credentials]

👉 [Read Full API Documentation]

👉 [Talk to Our Technical Team on WhatsApp]

Techto Networks — India's MSG API. HTTP REST + SMPP. TRAI DLT Compliant. Every Indian Network. 2026