SMS API Integration for CRMs and E-commerce Platforms in India
Updated: Sep 29
By TechTo Networks · Originally published May 22, 2025 · Reviewed and updated periodically
Not every SMS API integration in India needs a custom backend service. If your team already runs on Zoho CRM, Shopify, WooCommerce, or even a well-organized Google Sheet, you can trigger DLT-compliant SMS from events in those platforms directly — no dedicated developer team required, though someone technical will still need to set up the initial connection.
This page covers that path specifically. If you're building a custom application and need queueing, retry logic, and production-grade architecture, the developer integration guide is the deeper resource for that. If you just want to understand a single API call, start with sending your first SMS via API.
A Quick Recap of the Real API
TechTo's SMS API is an HTTP GET, query-parameter API — not the JSON REST API with API-key headers that generic integration tutorials often assume. Every example below builds on the actual documented structure:
A successful call returns a numeric message ID as plain text; a failure returns a numeric error code (invalid sender, invalid number, template mismatch, low credits, and others — see the full reference for the complete list). The token-authenticated variant additionally supports delivery-report and credit-balance lookups returning JSON — useful for platform integrations that want to check a message's status after sending. This matters for the examples below: since it's a plain HTTP GET request, any platform that can make an outbound HTTP call — which includes virtually every modern CRM, e-commerce platform, and automation tool — can call it directly, without needing an SDK.
The General Pattern
Regardless of which platform you're connecting, the shape is the same:
An event happens in your platform — a new lead, an order placed, a form submitted.
The platform fires an outbound call — either natively (a script step, an action hook) or via a webhook to a small piece of middleware you control.
That call hits TechTo's API with the recipient number, sender ID, route, and message text populated from the event data.
The message is sent, and (optionally) you log the returned message ID back into your platform for reference.
The main design decision per platform is whether it can call an external HTTP GET request natively (Zoho and WooCommerce can) or whether it only sends outbound webhooks that need a small piece of middleware to translate into the GET request TechTo expects (Shopify's native webhooks are JSON POST, so they need this extra step).
Zoho CRM Integration
Zoho CRM supports custom functions written in Deluge script, which can make outbound HTTP calls directly — no middleware required.
Setting it up:
In Zoho CRM, go to Setup → Automation → Actions → Functions and create a new custom function.
Write a Deluge function that fires on the event you want (lead created, deal stage changed, ticket closed).
Attach the function to a Workflow Rule for that event.
// Zoho Deluge custom function
mobile_number = input.Mobile;
sender_id = "TECHTO"; // your registered DLT sender ID
message_text = "Hi " + input.Last_Name + ", thanks for your interest! Our team will reach out shortly. -TechTo";
api_url = "http://godspeed.liveair.co.in/httpapi/tally";
params = Map();
params.put("username", "your_username");
params.put("password", "your_password");
params.put("sender", sender_id);
params.put("number", mobile_number);
params.put("route", "2"); // Transactional
params.put("type", "1"); // Text
params.put("sms", message_text);
response = invokeurl
[
url: api_url
type: GET
parameters: params
];
info response; // logs the returned message ID or error code
Important: the message_text above must exactly match your DLT-registered template, with only the variable portion (the recipient's name, in this example) changing. Deluge makes it easy to concatenate dynamic strings — resist the temptation to compose freeform messages this way for anything beyond the variable fields your template actually has registered, since template mismatches are blocked at the carrier level regardless of which platform triggered the send.
Shopify Integration
Shopify's webhook system sends a JSON payload via POST when an event occurs (orders/create, orders/fulfilled, checkouts/create for abandoned-cart scenarios). Because this is a POST with a JSON body — not the GET request TechTo's API expects — you need a small piece of middleware in between. Two practical options:
Option A: A lightweight serverless function. Deploy a small function (on any platform — a basic Node.js or Python function works) that receives Shopify's webhook, extracts the relevant fields, and makes the GET call to TechTo's API.
// Example: a minimal Node.js webhook receiver (e.g., on a serverless platform)
const https = require('https');
exports.handler = async (event) => {
const order = JSON.parse(event.body);
const phone = order.customer?.phone?.replace(/\D/g, ''); // strip non-digits
if (!phone) return { statusCode: 200, body: 'No phone on order' };
const params = new URLSearchParams({
username: process.env.TECHTO_USERNAME,
password: process.env.TECHTO_PASSWORD,
sender: 'TECHTO',
number: phone,
route: '2',
type: '1',
sms: `Hi! Your order #${order.order_number} is confirmed. We'll notify you when it ships. -TechTo`,
});
await new Promise((resolve, reject) => {
https.get(`http://godspeed.liveair.co.in/httpapi/tally?${params}`, resolve).on('error', reject);
});
return { statusCode: 200, body: 'SMS triggered' };
};
Register this function's URL in Shopify's webhook settings (Settings → Notifications → Webhooks) for the events you want.
Option B: A no-code automation tool (Zapier, Make, or similar) with Shopify as the trigger and a generic "Webhooks" or "HTTP request" action calling TechTo's API as the action step. This avoids writing and hosting any code, at the cost of ongoing subscription fees for the automation platform and less control over error handling than a custom function gives you. See the "No-Code Automation Platforms" section below for how to configure this generically, since TechTo does not currently have a dedicated, official Zapier or Make app to configure this out of the box — confirm current status before assuming otherwise.
WooCommerce Integration
WordPress and WooCommerce support PHP action hooks that fire on order lifecycle events, and PHP can make the HTTP GET call directly using WordPress's built-in HTTP functions — no separate middleware needed.
<?php
// Add to your theme's functions.php or a custom plugin
add_action('woocommerce_order_status_changed', function($order_id, $old_status, $new_status) {
if ($new_status !== 'processing') return; // only fire on order confirmation
$order = wc_get_order($order_id);
$phone = preg_replace('/\D/', '', $order->get_billing_phone());
if (!$phone) return;
$params = http_build_query([
'username' => getenv('TECHTO_USERNAME'),
'password' => getenv('TECHTO_PASSWORD'),
'sender' => 'TECHTO',
'number' => $phone,
'route' => 2,
'type' => 1,
'sms' => sprintf('Hi %s, your order #%s is confirmed. -TechTo', $order->get_billing_first_name(), $order->get_order_number()),
]);
wp_remote_get("http://godspeed.liveair.co.in/httpapi/tally?$params", ['timeout' => 10]);
}, 10, 3);
Use wp_remote_get() rather than PHP's raw curl functions where possible — it's WordPress's standard HTTP client, handles timeouts consistently with the rest of your site, and is easier for another WordPress developer to maintain later.
Google Sheets and Spreadsheet-Triggered SMS
For teams that manage contact lists or event tracking in a spreadsheet rather than a full CRM, Google Apps Script can trigger sends directly from a Google Sheet — useful for smaller-scale, manually-curated sends (a sales team's daily follow-up list, an events team's RSVP confirmations).
// Google Apps Script, bound to a Google Sheet
function sendSmsFromRow(row) {
const sheet = SpreadsheetApp.getActiveSheet();
const number = sheet.getRange(row, 1).getValue(); // column A: phone number
const name = sheet.getRange(row, 2).getValue(); // column B: name
const status = sheet.getRange(row, 4).getValue(); // column D: send status
if (status === 'SENT') return; // avoid duplicate sends
const message = `Hi ${name}, this is a reminder about your upcoming appointment. -TechTo`;
const params = {
username: PropertiesService.getScriptProperties().getProperty('TECHTO_USERNAME'),
password: PropertiesService.getScriptProperties().getProperty('TECHTO_PASSWORD'),
sender: 'TECHTO', number: number, route: '2', type: '1', sms: message,
};
const query = Object.entries(params).map(([k, v]) => `${k}=${encodeURIComponent(v)}`).join('&');
const response = UrlFetchApp.fetch(`http://godspeed.liveair.co.in/httpapi/tally?${query}`);
sheet.getRange(row, 4).setValue('SENT');
sheet.getRange(row, 5).setValue(response.getContentText()); // log message ID or error code
}
function sendToAllPending() {
const sheet = SpreadsheetApp.getActiveSheet();
const lastRow = sheet.getLastRow();
for (let row = 2; row <= lastRow; row++) {
if (sheet.getRange(row, 4).getValue() !== 'SENT') sendSmsFromRow(row);
Utilities.sleep(200); // avoid firing requests faster than the API can handle
}
}
Store credentials in Script Properties (File → Project Properties → Script Properties in the Apps Script editor), never hardcoded in the script itself, since a shared sheet with an editor who can view the script would otherwise expose them.
No-Code Automation Platforms (Zapier, Make, Pabbly Connect)
If you'd rather not write or host any code, a general-purpose automation tool can connect almost any trigger (a new form submission, a new row in a sheet, an event from hundreds of supported apps) to TechTo's API using a generic HTTP or webhook action, since TechTo's API doesn't require anything beyond a standard GET request:
Set up your trigger app and event as normal (for example, "New row in Google Sheets" or "New order in Shopify").
Add an action step using your platform's generic "Webhooks" or "HTTP Request" action type (available in Zapier, Make, and most similar tools).
Configure it as a GET request to http://godspeed.liveair.co.in/httpapi/tally, with your credentials, sender ID, route, type, and message mapped as query parameters from your trigger's data.
Test with a single real send before turning on the automation for live traffic.
This approach trades some control and error-handling sophistication for setup speed — reasonable for lower-volume, less time-sensitive use cases, and worth moving off of toward a proper backend integration (see below) once volume or reliability requirements grow.
DLT Considerations Specific to Platform-Triggered Sends
Everything covered in TechTo's DLT and TRAI regulations resource applies the same way here as it does to a custom backend integration — DLT doesn't care which platform originated the API call. A few things worth extra attention specifically because these integrations are often set up and maintained by non-developers:
Lock down message text to the registered template. It's tempting, in a low-code tool like Zoho's Deluge or a Zapier field mapper, to let a marketing team member freely edit message wording. Don't — build the template as a fixed string with only the genuinely variable fields (name, order number) pulled from platform data, and treat the fixed portions as immutable without a corresponding DLT resubmission.
Route selection needs to be explicit, not assumed. A workflow automatically firing "order confirmed" messages should use the Transactional route; a marketing campaign triggered from a CRM segment should use Promotional. Misconfiguring this in a no-code tool is easy to do once and then repeat silently across every future send until someone notices.
Test the actual platform trigger, not just the API call in isolation. A Deluge function or Apps Script that works when run manually can behave differently when fired by a real workflow trigger — test with a genuine event (a real test order, a real test lead) before relying on it in production.
Common Mistakes with Platform Integrations
Hardcoding credentials directly in a script visible to multiple team members. Use each platform's secrets/properties mechanism (Script Properties in Apps Script, environment variables in a serverless function) rather than a plaintext credential in a shared script or workflow.
No duplicate-send protection. A workflow that fires on every save of a CRM record, rather than specifically on creation or a status change, can send the same SMS repeatedly. Build an explicit status flag (as in the Google Sheets example above) or trigger condition to prevent this.
Assuming the automation platform retries failures for you. Not every no-code tool retries a failed HTTP action automatically, and even those that do may not distinguish a retryable error (a timeout) from a permanent one (an invalid template) the way custom code can. Check your specific tool's retry behavior rather than assuming it matches what you'd build yourself.
Letting a no-code integration grow past the point it should have become a real backend service. A single Zapier automation firing a few dozen messages a day is fine; the same pattern handling thousands of time-sensitive OTPs a day is a sign to migrate to the architecture covered in the developer integration guide.
Choosing Between the Platforms Covered Here
Not every business needs all four integration patterns above. A rough guide to which fits your situation:
If your team runs sales and support through Zoho CRM, the Deluge approach is usually the fastest to set up, since it needs no separate hosting and runs entirely inside a platform your team already uses daily.
If you run an e-commerce store on Shopify, weigh the serverless-function approach against a no-code tool based on your team's technical comfort: a function gives you more control over error handling and logging, while a no-code tool gets you running faster without any hosting to manage, at an ongoing subscription cost.
If your site runs on WordPress/WooCommerce, the PHP hook approach is usually the most natural fit, since it lives directly in your existing site codebase without a separate service to maintain, and most WooCommerce developers are already comfortable with action hooks.
If your data lives in a spreadsheet — a sales team's manually curated follow-up list, an events team's RSVP tracker — the Google Sheets approach avoids introducing a CRM or e-commerce platform at all for what might be a fairly simple, lower-volume use case.
If none of the above quite fits, or you're connecting a platform not covered specifically here, the general pattern still applies: find how your platform makes outbound HTTP calls (natively or via webhook-to-middleware), and map its event data onto TechTo's documented query parameters the same way the examples above do.
Measuring Whether a Platform Integration Is Actually Working
Once live, a few checks are worth building into your workflow rather than assuming silent success:
Log the API response, not just "sent." Every example above logs the raw response from TechTo's API (a message ID on success, an error code on failure) back into the originating platform — a CRM field, a spreadsheet column, a function's logs. Without this, a failing integration can run silently for weeks with nobody noticing, since most of these platforms won't surface an SMS failure as a workflow error on their own.
Spot-check a sample of real sends periodically, not just when something is reported broken. A template that was correct at setup can drift out of compliance if the underlying DLT template is ever resubmitted with different wording, and a platform integration is exactly the kind of thing that can keep quietly sending a now-mismatched message until it's checked.
Watch for a pattern of the same error code repeating. A single failed send might be a bad phone number; the same error code across many sends from one integration usually points to a configuration issue — an expired credential, a route misconfiguration, or a template that no longer matches — worth investigating as soon as the pattern appears rather than after a backlog builds up.
Reconcile message counts periodically between your platform's trigger count (how many times the automation fired) and TechTo's sent count, to catch silent drops — a workflow that appears to be running but isn't actually reaching the API due to a credential or network issue.
When to Move to a Custom Backend Integration
Platform-triggered SMS works well until one of a few thresholds gets crossed:
Volume grows to the point where per-message platform-automation costs (Zapier and similar tools typically charge per task) exceed the cost of hosting a small custom service.
Timing becomes critical — OTPs, for instance, generally deserve the queue-and-retry discipline covered in the developer integration guide rather than a no-code webhook chain with less predictable latency.
You need idempotency guarantees that a generic automation tool doesn't provide out of the box — critical for anything where a duplicate send has a real cost (a payment confirmation, for example).
You need detailed monitoring — error-code breakdowns, delivery-rate tracking by route — beyond what a platform's built-in automation history log shows.
None of this means platform-triggered integration is a lesser approach — it's the right tool for a real range of use cases. It's worth recognizing the point where the tradeoffs shift, rather than scaling a no-code workaround well past where it was ever meant to go.
Frequently Asked Questions SMS API Integration India
Can I integrate TechTo's SMS API into Zoho CRM without writing code?
Zoho's Deluge script requires a small amount of code, but it's simpler than a full backend service the example above is a complete, working starting point you can adapt. Alternatively, a no-code automation tool with Zoho as a trigger app can avoid writing Deluge entirely.
Does TechTo have an official Shopify app?
Not confirmed as part of this project's verified records. This guide assumes you'll connect via a webhook-to-middleware pattern or a generic automation tool's HTTP action instead. Confirm current app-marketplace availability directly with TechTo.
Is a no-code integration (Zapier, Make) as reliable as custom code?
For low-to-moderate volume and non-time-critical messages, generally yes. For high-volume or latency-sensitive sends (OTPs in particular), a custom backend with the retry and queueing discipline covered in the developer integration guide is the more reliable choice.
Can I send OTPs through a CRM or e-commerce platform integration?
Technically yes, using the same API call shown above with the OTP route, but OTP flows generally benefit from the tighter latency and reliability control that a dedicated backend service provides rather than a general-purpose automation platform — see the "When to Move to a Custom Backend" section above.
How do I keep message templates DLT-compliant when non-developers are configuring the integration?
Build the fixed template text into the code or automation step itself (as shown in every example above) rather than exposing it as an editable field to whoever configures the workflow, and document clearly which fields are the genuinely variable ones.
What happens if my platform's automation tool goes down — do I lose messages? Depends entirely on the tool. Some automation platforms queue and retry; others silently drop a failed run. Check your specific tool's documented behavior, and for anything where a lost message has a real cost, that's a signal to move to the custom backend approach covered in the developer integration guide.
Do I need a different TechTo account or credentials for each platform integration?
No — the same account credentials work across every integration shown here, since each one is simply a different way of making the same underlying API call. Using a single set of credentials also makes it easier to monitor total usage and credit balance across all your integrations in one place.
Can I use the same sender ID and templates across CRM, e-commerce, and spreadsheet integrations?
Yes, provided the message content matches the registered template exactly regardless of which platform triggers it. It's common to reuse one "order confirmation" template across both a Shopify integration and a manual spreadsheet-based fallback, as long as both send the identical registered wording.
Is it safe to test these integrations with real customer phone numbers?
Test with numbers your team controls first, especially while confirming a new template or route is correctly configured. Once verified on test numbers, a small, deliberate rollout to real traffic is more prudent than switching a full customer base over to an untested automation at once.
What happens if I change a DLT template's registered wording after a platform integration is already live?
Every integration point that references the old template needs updating simultaneously — the Deluge function, the serverless function, the WooCommerce hook, whichever you're using — since a template resubmission creates a new template ID with its own approval. Keep a documented list of which integrations reference which templates so a resubmission doesn't leave one quietly sending against an outdated version.
What's Changed
This page is reviewed periodically rather than rewritten on a fixed schedule. This revision replaced a version describing a fictional REST API and unverified rate limits and delivery-speed claims, and narrowed the page's scope specifically to platform and CRM integration — the custom backend and production-architecture content that used to overlap with this page now lives exclusively in the developer integration guide.
Next Steps
Pick the integration path that matches your platform above, test with a real event before relying on it in production, and confirm your DLT template and route selection are locked down in the automation itself. If your needs outgrow a platform-triggered approach, the developer integration guide covers what a custom backend integration looks like.
Comments