SMS API Integration India: The Complete Developer Guide with DLT Compliance & Code Examples (2026)
- TechTo Networks
- May 22, 2025
- 14 min read
Updated: May 5
If you are building an application, SaaS platform, or backend system in India that needs to send OTPs, transactional alerts, or automated notifications via SMS, you are navigating a messaging infrastructure that is unlike any other market in the world.
India's TRAI (Telecom Regulatory Authority of India) requires every commercial SMS — including system-generated OTPs and automated transactional alerts — to carry a registered Entity ID, Header ID, and Template ID in the API request. Without these DLT parameters, your message is blocked at the telecom operator level before delivery, regardless of your code quality or platform choice.
This complete SMS API integration guide for India covers everything developers need: how India's SMS API infrastructure works, the DLT compliance parameters your API calls must include, REST API integration with PHP, Python, Node.js, and Java code examples, OTP routing requirements, webhook delivery receipt implementation, and how to choose an SMS API provider that gives you the infrastructure reliability and developer documentation your application demands.
How India's SMS API Infrastructure Works — What Every Developer Must Understand First
Before writing a single line of integration code, every developer building for the Indian market must understand how India's regulated SMS delivery chain works. This is fundamentally different from SMS API integration in the US or Europe.
The Indian SMS Delivery Chain:
Your Application
↓
SMS API Request (with DLT parameters)
↓
SMS Gateway (e.g. TechTo Networks)
↓
DLT Validation (TRAI's blockchain registry)
↓
Telecom Operator (Jio / Airtel / Vodafone-Idea / BSNL)
↓
Recipient's Mobile DeviceEvery step in this chain has a compliance requirement:
Your application sends an API request that must include your registered Entity ID, the registered Template ID matching your exact message, and the registered Header (Sender ID). The SMS gateway receives the request, validates your DLT parameters, and routes the message to the appropriate telecom operator. The DLT system validates the Entity ID, Header, and Template ID against its blockchain registry in real time. If all three match, the message is delivered. If any mismatch exists — even a single character difference between your message content and the registered template — the message is blocked.
The practical implication for developers: You cannot build an SMS integration in India the way you would build a Twilio integration in the US. You cannot dynamically generate message content. Every message must match a pre-approved, pre-registered DLT template exactly — with only the defined variable fields ({#var#}) changing per-message. Building this constraint correctly into your application architecture from day one prevents delivery failures at scale.
Prerequisites — What You Need Before Writing Integration Code
Before integrating TechTo Networks' SMS API, ensure all of the following are in place:
1. DLT Entity Registration
Your organisation must be registered as a Principal Entity (PE) on a TRAI DLT portal. In India, the major DLT portals are:
Jio DLT — trueconnect.jio.com
Airtel DLT — dltconnect.airtel.in
Vodafone-Idea DLT — smartping.com
BSNL DLT — www.ucc.bsnl.co.in
Tata DLT — tatatelebusiness.com/dlt
Registration requires GST certificate, PAN, and company incorporation documents. Once approved, you receive your Entity ID (PE ID) — a unique identifier for your organisation in the DLT system. This ID is required in every API request your application sends.
2. Sender Header (Sender ID) Registration
Your Sender Header is the 6-character alphabetic identifier that appears in the recipient's inbox as the message sender (e.g., TM-TECHTO, TM-MYAPP, AM-ORDRS). It must be registered and approved on DLT before use. Header approval typically takes 24–48 hours on most DLT portals.
The prefix convention as of 2025:
TM- = Transactional messages
AM- = Service (implicit) messages
VM- = Service (explicit) messages
BM- = Promotional messages (numeric only — e.g., BM-123456)
3. DLT Message Template Registration and Template ID
Every message your application sends must match a pre-approved DLT template. Variable fields are defined in the template using {#var#} syntax. Each approved template is assigned a unique Template ID by the DLT portal.
Example DLT-registered template:
Your OTP for {#var#} is {#var#}. Valid for {#var#} minutes.
DO NOT share this code with anyone. -{#var#}Template ID (assigned by DLT portal): 1107161234567890123
Your API call must include this Template ID exactly. The message content sent in the API request must match the approved template with only the {#var#} fields replaced by actual values.
4. TechTo Networks API Credentials
Sign up at TechTo Networks to receive your:
API Key — Used for request authentication
Sender Header — Your registered DLT Header ID
Account balance — SMS credits for your chosen route
TechTo Networks SMS API — Base URL and Authentication
Base URL:
Authentication: All API requests use API key authentication passed as a request header or query parameter.
Request header method (recommended):
X-API-Key: your_api_key_hereSupported HTTP methods: GET and POST. POST with JSON body is recommended for all production integrations — it handles Unicode characters and long messages correctly, and does not expose sensitive parameters in server logs.
Content type for POST requests:
Content-Type: application/jsonCore API Endpoint — Sending a Single SMS
Endpoint:
Required parameters:
Parameter | Type | Description |
mobile | string | Recipient mobile number with country code (e.g., 919876543210) |
sender | string | Your DLT-registered Header ID (e.g., TM-TECHTO) |
message | string | Message content — must match DLT template with {#var#} fields replaced |
route | string | SMS route: transactional, promotional, or otp |
entity_id | string | Your TRAI DLT Entity ID (PE ID) |
template_id | string | DLT Template ID for this message |
Optional parameters:
Parameter | Type | Description |
unicode | boolean | Set true for regional language messages (Malayalam, Hindi, Tamil, etc.) |
flash | boolean | Set true to send as flash SMS (displays without saving) |
schedule_time | string | ISO 8601 datetime for scheduled sends (e.g., 2025-10-20T10:30:00+05:30) |
callback_url | string | Webhook URL for delivery receipt callbacks |
Code Examples — SMS API Integration in Multiple Languages
PHP Integration Example
php
<?php
$apiKey = 'your_api_key_here';
$apiUrl = 'https://api.techtonetworks.com/v1/send';
$data = [
'mobile' => '919876543210',
'sender' => 'TM-TECHTO',
'message' => 'Your OTP is 482719. Valid for 10 minutes. DO NOT share this code with anyone. -TechTo',
'route' => 'otp',
'entity_id' => '1101234567890123456',
'template_id' => '1107161234567890123'
];
$ch = curl_init($apiUrl);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($data));
curl_setopt($ch, CURLOPT_HTTPHEADER, [
'Content-Type: application/json',
'X-API-Key: ' . $apiKey
]);
$response = curl_exec($ch);
$httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
curl_close($ch);
$result = json_decode($response, true);
if ($httpCode === 200 && $result['status'] === 'success') {
echo "Message sent. Message ID: " . $result['message_id'];
} else {
echo "Error: " . $result['message'];
}
?>Python Integration Example
python
import requests
import json
API_KEY = 'your_api_key_here'
API_URL = 'https://api.techtonetworks.com/v1/send'
headers = {
'Content-Type': 'application/json',
'X-API-Key': API_KEY
}
payload = {
'mobile': '919876543210',
'sender': 'TM-TECHTO',
'message': 'Your OTP is 482719. Valid for 10 minutes. DO NOT share this code with anyone. -TechTo',
'route': 'otp',
'entity_id': '1101234567890123456',
'template_id': '1107161234567890123'
}
try:
response = requests.post(API_URL, headers=headers, json=payload, timeout=10)
response.raise_for_status()
result = response.json()
if result.get('status') == 'success':
print(f"Message sent. Message ID: {result['message_id']}")
else:
print(f"API error: {result.get('message')}")
except requests.exceptions.Timeout:
print("Request timed out — implement retry logic")
except requests.exceptions.RequestException as e:
print(f"Request failed: {e}")Node.js Integration Example
javascript
const axios = require('axios');
const API_KEY = 'your_api_key_here';
const API_URL = 'https://api.techtonetworks.com/v1/send';
const sendSMS = async (mobile, message, templateId) => {
try {
const response = await axios.post(API_URL, {
mobile: mobile,
sender: 'TM-TECHTO',
message: message,
route: 'otp',
entity_id: '1101234567890123456',
template_id: templateId
}, {
headers: {
'Content-Type': 'application/json',
'X-API-Key': API_KEY
},
timeout: 10000
});
if (response.data.status === 'success') {
console.log(`Message sent. ID: ${response.data.message_id}`);
return response.data.message_id;
} else {
throw new Error(`API error: ${response.data.message}`);
}
} catch (error) {
if (error.code === 'ECONNABORTED') {
console.error('Request timed out — implement retry with exponential backoff');
} else {
console.error('SMS send failed:', error.message);
}
throw error;
}
};
// Usage
sendSMS('919876543210', 'Your OTP is 482719. Valid for 10 minutes. DO NOT share. -TechTo', '1107161234567890123');Java Integration Example
java
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.net.URI;
public class TechToSmsApi {
private static final String API_KEY = "your_api_key_here";
private static final String API_URL = "https://api.techtonetworks.com/v1/send";
public static String sendSMS(String mobile, String message, String templateId) throws Exception {
String jsonBody = String.format(
"{\"mobile\":\"%s\",\"sender\":\"TM-TECHTO\",\"message\":\"%s\"," +
"\"route\":\"otp\",\"entity_id\":\"1101234567890123456\",\"template_id\":\"%s\"}",
mobile, message, templateId
);
HttpClient client = HttpClient.newHttpClient();
HttpRequest request = HttpRequest.newBuilder()
.uri(URI.create(API_URL))
.header("Content-Type", "application/json")
.header("X-API-Key", API_KEY)
.POST(HttpRequest.BodyPublishers.ofString(jsonBody))
.build();
HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());
if (response.statusCode() == 200) {
return response.body(); // Parse JSON response for message_id
} else {
throw new RuntimeException("SMS API error: HTTP " + response.statusCode());
}
}
public static void main(String[] args) throws Exception {
String result = sendSMS(
"919876543210",
"Your OTP is 482719. Valid for 10 minutes. DO NOT share. -TechTo",
"1107161234567890123"
);
System.out.println("API Response: " + result);
}
}cURL Example (Testing and Shell Scripts)
bash
curl -X POST https://api.techtonetworks.com/v1/send \
-H "Content-Type: application/json" \
-H "X-API-Key: your_api_key_here" \
-d '{
"mobile": "919876543210",
"sender": "TM-TECHTO",
"message": "Your OTP is 482719. Valid for 10 minutes. DO NOT share this code with anyone. -TechTo",
"route": "otp",
"entity_id": "1101234567890123456",
"template_id": "1107161234567890123"
}'API Response Format and Error Handling
Successful response (HTTP 200):
json
{
"status": "success",
"message_id": "TECHTO-20251005-48271900",
"mobile": "919876543210",
"credits_used": 1,
"credits_remaining": 4999,
"route": "otp",
"submitted_at": "2025-10-05T10:30:00+05:30"
}Error response examples:
json
// DLT Template ID mismatch
{
"status": "error",
"error_code": "DLT_TEMPLATE_MISMATCH",
"message": "Message content does not match registered DLT template ID 1107161234567890123",
"action": "Verify your message matches the approved template exactly"
}json
// Invalid mobile number format
{
"status": "error",
"error_code": "INVALID_MOBILE",
"message": "Mobile number 9876543210 is invalid — must include country code (e.g., 919876543210)"
}json
// Insufficient credits
{
"status": "error",
"error_code": "INSUFFICIENT_BALANCE",
"message": "Account balance insufficient. Current balance: 0 credits.",
"action": "Recharge your account at techtonetworks.com/billing"
}Standard HTTP status codes:
Code | Meaning |
200 | Message accepted for delivery |
400 | Bad request — invalid parameters or DLT mismatch |
401 | Unauthorised — invalid API key |
402 | Payment required — insufficient credits |
429 | Rate limit exceeded — too many requests per second |
500 | Server error — retry with exponential backoff |
Bulk SMS API — Sending to Multiple Recipients
For sending the same message to multiple recipients simultaneously (campaign sends, alert broadcasts), use the bulk endpoint:
Endpoint:
Request body:
json
{
"sender": "TM-TECHTO",
"route": "promotional",
"entity_id": "1101234567890123456",
"template_id": "1107169876543210987",
"messages": [
{
"mobile": "919876543210",
"message": "Hi Priya! Diwali Sale is LIVE — 30% off everything today. Shop: https://yourdomain.in Reply STOP to opt out -TechTo"
},
{
"mobile": "917654321098",
"message": "Hi Rahul! Diwali Sale is LIVE — 30% off everything today. Shop: https://yourdomain.in Reply STOP to opt out -TechTo"
}
]
}Bulk API limits and best practices:
Maximum recipients per bulk request: 500 numbers. For campaigns above 500 recipients, batch your requests and implement a queue with rate limiting — do not fire all batches simultaneously or you will hit the rate limiter (HTTP 429). Recommended throughput: 200–300 messages per second on transactional routes, 100 messages per second on promotional routes. Build exponential backoff retry logic for any batch that returns HTTP 500 or 429.
Webhook Delivery Receipts — Knowing When Your Message Was Delivered
For production SMS applications — particularly OTP delivery, financial alerts, and compliance-critical notifications — you need real-time confirmation that each message was delivered to the recipient's device. TechTo Networks' webhook system provides per-message delivery receipt callbacks.
Setting up your webhook:
Pass your callback URL in the initial send request:
json
{
"mobile": "919876543210",
"sender": "TM-TECHTO",
"message": "...",
"route": "otp",
"entity_id": "1101234567890123456",
"template_id": "1107161234567890123",
"callback_url": "https://yourdomain.in/webhook/sms-delivery"
}Webhook payload (POST to your callback_url):
json
{
"message_id": "TECHTO-20251005-48271900",
"mobile": "919876543210",
"status": "DELIVERED",
"delivered_at": "2025-10-05T10:30:04+05:30",
"operator": "JIO",
"route": "otp",
"latency_ms": 3840
}Delivery status values:
Status | Meaning | Action |
DELIVERED | Confirmed delivery to handset | No action required |
PENDING | In queue at telecom operator | Wait — usually resolves in 30s |
FAILED | Delivery failed permanently | Log and trigger fallback |
UNDELIVERED | Handset unreachable (switched off, no coverage) | Retry after interval |
DND | Number is DND-registered and route is Promotional | Remove from promotional list |
INVALID | Number does not exist or is not a mobile number | Remove from database |
PHP webhook handler example:
php
<?php
// sms-delivery-webhook.php
$payload = json_decode(file_get_contents('php://input'), true);
if (!$payload || !isset($payload['message_id'])) {
http_response_code(400);
exit;
}
$messageId = $payload['message_id'];
$status = $payload['status'];
$mobile = $payload['mobile'];
$operator = $payload['operator'];
// Log delivery receipt to your database
logDeliveryStatus($messageId, $status, $mobile, $operator);
// Handle failed OTP deliveries
if ($status === 'FAILED' && isOtpMessage($messageId)) {
triggerOtpRetry($mobile);
}
// Acknowledge receipt to TechTo
http_response_code(200);
echo json_encode(['received' => true]);
?>DLT-Compliant Integration — The India-Specific Requirements Every Developer Must Handle
This section is the most critical for Indian SMS integration and is not covered adequately by any competitor. Read it completely before deploying to production.
Requirement 1: Entity ID and Template ID Are Mandatory API Parameters
Unlike SMS APIs in the US or Europe where you simply provide a phone number, sender ID, and message text, India's DLT framework requires your API request to include your Entity ID (PE ID) and the Template ID of the specific pre-approved template you are sending. If either is missing or incorrect, the message is blocked at the telecom level.
Build these into your API integration as constants or configuration values — not as dynamic or user-inputtable values. Your entity_id never changes. Your template_ids are fixed per message type and must be stored securely in your application configuration.
Requirement 2: Your Message Must Match the Registered Template Exactly
The DLT system performs a real-time content match between the message you send and the approved template associated with the Template ID in your request. Only the {#var#} variable positions can differ. The fixed text must match character-for-character.
What this means in practice:
If your approved template is:
Your OTP for {#var#} is {#var#}. Valid for {#var#} minutes. DO NOT share this code with anyone. -{#var#}Your sent message must be something like:
Your OTP for login is 482719. Valid for 10 minutes. DO NOT share this code with anyone. -TechToYou cannot add extra words, change punctuation, or alter the fixed text. Even adding "Please" before "DO NOT" will cause a DLT mismatch block.
Developer implementation advice: Store your DLT template strings in your application code as template literals with placeholders, and build a template renderer that only populates the variable positions — never allows arbitrary message composition for regulated SMS types.
Requirement 3: Route Selection Must Match Message Type
Message Type | Correct API Route | Can Reach DND? | Time Restriction |
OTP / Authentication | otp | ✅ Yes | None |
Order confirmation, payment receipt | transactional | ✅ Yes | None |
Marketing offers, flash sales | promotional | ❌ No | 9 AM–9 PM only |
EMI reminders, KYC alerts | service | ✅ (category-dependent) | Varies |
Critical error: Using promotional route for OTP or transactional messages will cause DND-registered customers to never receive your OTPs or order alerts. This is one of the most common and costly SMS integration mistakes in India.
Requirement 4: Unicode Handling for Regional Language Templates
If your application sends SMS in Hindi, Tamil, Telugu, Malayalam, or any other Indian language, set "unicode": true in your API request. Unicode messages use 70 characters per SMS segment instead of 160. Your DLT template for Unicode messages must also be submitted as a Unicode template during DLT registration — you cannot use an ASCII template for Unicode messages.
Requirement 5: URL Whitelisting in DLT Templates
If your SMS includes a link, the domain must be registered as a whitelisted URL in your DLT template. Unregistered domains in SMS links are blocked by telecom operators. Register your tracking or landing page domain in your DLT template during submission using the {#var#} field for the URL.
Sending Bulk SMS via API — Handling DLT at Scale
When sending bulk SMS campaigns via API, the DLT compliance requirements apply to every single message — not just the campaign as a whole.
Pre-campaign compliance checklist for developers:
Before triggering a bulk API send, your application should validate:
The Template ID being used matches the message type (promotional vs transactional). The registered template supports the variable fields you plan to populate. All recipient numbers are in the correct format (91XXXXXXXXXX for India). If using the promotional route, your contact list has been DND-scrubbed. The send time falls within 9 AM–9 PM IST for promotional route sends.
Implementing DND scrubbing via API:
python
import requests
def check_dnd_status(mobile_numbers, api_key):
"""
Check DND status for a list of mobile numbers
Returns dict of {mobile: is_dnd}
"""
response = requests.post(
'https://api.techtonetworks.com/v1/dnd/check',
headers={'X-API-Key': api_key, 'Content-Type': 'application/json'},
json={'mobiles': mobile_numbers}
)
return response.json().get('results', {})
# Filter out DND numbers before promotional sends
def send_promotional_campaign(contact_list, message, template_id, api_key):
dnd_status = check_dnd_status(contact_list, api_key)
eligible = [num for num in contact_list if not dnd_status.get(num, False)]
print(f"Total: {len(contact_list)} | DND filtered: {len(contact_list) - len(eligible)} | Eligible: {len(eligible)}")
# Batch and send to eligible numbers
batch_size = 500
for i in range(0, len(eligible), batch_size):
batch = eligible[i:i + batch_size]
send_batch(batch, message, template_id, api_key)CRM and Platform Integrations
TechTo Networks' SMS API integrates with all major platforms used by Indian businesses:
Zoho CRM Integration Zoho CRM supports custom functions using Deluge script that can call external REST APIs. Configure TechTo Networks' API endpoint in Zoho's custom function settings to trigger SMS on CRM events — lead assignment, deal stage change, support ticket creation, or follow-up reminders.
Shopify Integration Use Shopify's webhook system to trigger TechTo Networks' API calls on order events — orders/create, orders/fulfillment_create, and checkouts/create for abandoned cart recovery. Implement a lightweight Node.js or PHP middleware server to receive Shopify webhooks and forward to TechTo's API with DLT parameters.
WooCommerce Integration WooCommerce provides PHP action hooks for all order lifecycle events. Use woocommerce_order_status_changed and woocommerce_checkout_order_processed hooks to trigger TechTo's API with the customer's billing phone, the relevant transactional template, and your Entity ID and Template ID.
Custom ERP and LMS Integration For SAP, Tally, or custom-built ERP and loan management systems, TechTo Networks' REST API integrates directly via HTTP POST from any server-side language. The API is stateless and requires no SDK installation — any system capable of making an HTTPS POST request with a JSON body can integrate in under 2 hours.
Rate Limits, Reliability, and Production Best Practices
API Rate Limits by Route:
Route | Max per Second | Max per Hour |
OTP | 200 msg/sec | Unlimited |
Transactional | 500 msg/sec | Unlimited |
Promotional | 100 msg/sec | As per campaign limits |
Building for production reliability:
Implement exponential backoff for rate limit errors:
python
import time
import random
def send_with_retry(payload, api_key, max_retries=3):
for attempt in range(max_retries):
response = requests.post(API_URL, headers={'X-API-Key': api_key}, json=payload)
if response.status_code == 200:
return response.json()
elif response.status_code == 429: # Rate limited
wait = (2 ** attempt) + random.uniform(0, 1)
time.sleep(wait)
elif response.status_code >= 500: # Server error
wait = (2 ** attempt) + random.uniform(0, 1)
time.sleep(wait)
else:
break # Client error — don't retry
raise Exception(f"SMS send failed after {max_retries} attempts")Store all Message IDs and delivery statuses in your database: For OTP flows, financial alerts, and any compliance-sensitive communication, every outbound SMS Message ID and its subsequent delivery status from the webhook must be logged. This creates an audit trail for dispute resolution and TRAI compliance review.
Monitor delivery rate in real time: Build an alert if your delivery rate on transactional or OTP routes drops below 95%. A delivery rate drop usually indicates a DLT template mismatch, a sender header issue, or a telecom operator routing problem — all of which need immediate investigation.
Test across all four major Indian operators: Before going to production, send test messages to Jio, Airtel, Vodafone-Idea, and BSNL numbers to verify delivery on all networks. Delivery behaviour can vary by operator, particularly for BSNL in rural areas.
CONCLUSION
Building a production-grade SMS integration in India is fundamentally different from any other market — TRAI's DLT framework requires every API call to carry verified Entity IDs, Template IDs, and Sender Headers, and every message to match a pre-approved template exactly. Getting these DLT parameters right in your application architecture is not an afterthought — it is the foundation.
TechTo Networks provides a TRAI DLT-compliant REST SMS API built for Indian developers — with dedicated OTP, transactional, promotional, and service routes, direct SMPP connections to all major Indian telecom operators, sub-5-second OTP delivery, real-time webhook delivery receipts, and a Thiruvananthapuram-based technical team that understands India's SMS compliance requirements from the ground up.
👉 Register for free API credentials today and test delivery across all four Indian telecom networks before committing to a plan.
FAQ
Q1: What DLT parameters are required in the SMS API request for India? Every commercial SMS API request in India must include three DLT parameters: your Entity ID (Principal Entity ID from your DLT portal registration), your Sender Header (registered 6-character Sender ID), and the Template ID of the pre-approved DLT template matching your message. Messages missing any of these parameters or whose content does not match the registered template are blocked by telecom operators before delivery.
Q2: How do I get an Entity ID for SMS API integration in India? Register your business as a Principal Entity on a TRAI DLT portal — the main options are Jio DLT (trueconnect.jio.com), Airtel DLT (dltconnect.airtel.in), Vodafone-Idea (smartping.com), or BSNL DLT. Registration requires your GST certificate, PAN, and company documents. Once approved (typically 24–72 hours), you receive your Entity ID. TechTo Networks assists with DLT entity registration as part of API onboarding.
Q3: What is the difference between OTP, transactional, and promotional SMS API routes in India? The OTP route is for authentication codes and delivers to all numbers with highest priority routing (sub-5-second delivery SLA). The transactional route is for system-triggered messages related to customer actions (order confirmations, payment alerts) and delivers to all numbers including DND. The promotional route is for marketing messages and can only deliver to non-DND numbers between 9 AM and 9 PM. Using the wrong route for OTPs or transactional messages causes delivery failures for DND-registered customers.
Q4: How do I handle DLT template matching in my application code? Store your approved DLT template strings as constants in your application configuration. Build a renderer that populates only the {#var#} variable positions with dynamic values — never allow arbitrary message composition for DLT-regulated SMS types. Even changing punctuation or adding a word to the fixed text portions of your message will cause a DLT mismatch block. Always test template rendering against the exact approved template before deploying new message types.
Q5: What is the SMS API delivery speed for OTP messages in India? TechTo Networks achieves average OTP delivery latency of under 5 seconds via direct SMPP connections to Jio, Airtel, and Vodafone-Idea. BSNL delivery averages 5–10 seconds. For OTP flows with session timeouts, build your application to allow at least 30 seconds for OTP delivery before showing a retry option — network congestion during peak hours (9–10 AM, 8–9 PM) can occasionally push delivery to 15–20 seconds even on priority routes.
Q6: How do I implement retry logic for failed SMS API requests in India? Implement exponential backoff for HTTP 429 (rate limit) and HTTP 500 (server error) responses — wait (2^attempt) seconds plus a random jitter between 0 and 1 second before retrying. For HTTP 400 errors (DLT mismatch, invalid template), do not retry — investigate and fix the template or parameter error first. Store all Message IDs from successful API responses and cross-reference with webhook delivery statuses to identify messages that need application-level retry (e.g., FAILED or UNDELIVERED status).
Comments