SMS QR Code API Guide

An SMS QR code encodes a URI that tells the scanning phone to open its messaging app with a recipient number — and optionally a pre-filled message body — already populated. The customer scans, the compose screen opens, and all they do is press send.

There is no API call involved in that flow at all, which is the first thing to be clear about in any sms qr code api discussion. The "API" people are searching for is one of two quite different things: the payload format you encode (a URI standard, not a web service), or a code-generation library you call from your own backend to produce the image. This guide covers both, and states plainly at the end what SMLLR's own REST API does and does not cover.

There are two competing conventions, and picking the wrong one is the most common cause of an SMS QR code that works on one phone and not another.

The sms: URI scheme is the modern, widely supported form:

sms:+919876543210?body=Hi%2C%20I%20want%20to%20order

The number should be in international E.164 format (+91 for India), and the body must be percent-encoded. This is the format SMLLR builds when you create an SMS QR code — the number is stripped to digits and +, and the body is URI-encoded before being appended.

The SMSTO: format is the older Denso Wave convention:

SMSTO:+919876543210:Hi, I want to order

It is still recognised by many dedicated scanner apps but is less consistently handled by native phone cameras, which is where the overwhelming majority of real-world scans happen in India. For anything printed for the public, prefer sms:.

A third variant, sms:+91...&body=... (ampersand instead of question mark), appears in some older documentation. It is handled inconsistently. Use the ?body= form.

SMS URI handling is genuinely inconsistent across platforms, and this is not something you can reason your way around — it has to be tested on real devices.

• iOS. Historically Apple has been stricter about pre-filled bodies than Android, and behaviour has changed across iOS versions. A body that populates correctly on one version may be dropped on another.
• Android. Generally more permissive with ?body=, but the default SMS app varies by manufacturer, and some OEM messaging apps handle the parameter differently from the stock app.
• Native camera vs scanner app. A phone's built-in camera may show a tappable "Send message" prompt, while a third-party scanner app may show the raw URI text. Both work; they look different to the user.
• Special characters. Emoji, line breaks and non-Latin scripts in the body are the least reliably handled part of the whole format. If your pre-filled message must contain Hindi or Tamil text, test it specifically.

The practical implication: design the campaign so it still works if the body is dropped. If the entire mechanism depends on a keyword the customer must send, put that keyword on the printed piece as well — "scan and send, or SMS OFFER to 9876543210" — so a phone that strips the body does not break the funnel.

If you need to produce SMS QR codes in bulk from your own systems — one per dealer, per store, per sales rep — you generate them in your own backend using a QR encoding library. There is no web service required.

In Python, using the qrcode library:

import qrcode
from urllib.parse import quote

def sms_qr(number: str, body: str, out_path: str):
    payload = f"sms:{number}?body={quote(body)}"
    img = qrcode.make(payload)
    img.save(out_path)

sms_qr("+919876543210", "Hi, I want to order", "dealer_001.png")

In Node.js, using the qrcode package:

const QRCode = require('qrcode');

const payload = `sms:+919876543210?body=${encodeURIComponent('Hi, I want to order')}`;
await QRCode.toFile('dealer_001.png', payload, { errorCorrectionLevel: 'Q' });

Our Python QR code API guide covers the library options in more depth, and API-first QR generation covers the architecture patterns for doing this at scale.

A raw sms: QR code has a property that matters more than most teams realise: it is completely invisible to analytics.

The scan opens the phone's messaging app directly. Nothing touches a server, so there is no scan event, no timestamp, no device breakdown, no per-placement attribution. You find out the campaign worked only when messages start arriving — and you have no way to tell which flyer, which dealer counter or which city produced them, unless you encoded a different keyword in every single code.

It is also permanently fixed. Change your business number and every printed SMS code is dead, with no fix short of a reprint.

This is the trade-off to make deliberately rather than by accident. A raw SMS code is the right choice when the messaging action is genuinely the whole point and you do not need attribution — a support shortcut on an appliance label, for instance. For a campaign you intend to measure, it is the wrong tool.

Being precise about the product, since this is where most "QR API" content gets vague:

In the dashboard, SMS is a first-class QR type available from the Starter plan (₹499/month). You enter the number and the message body, and SMLLR builds the sms: payload for you — no encoding work on your side.

The SMLLR REST API is read-only reporting. It exposes seven GET endpoints — account summary, QR list, single QR detail, campaign list, single campaign detail, client list, single client detail — under a versioned response contract, on the Premium plan (₹14,999/month), rate-limited to 60 requests per minute per API key. The @smllr/mcp-server MCP server wraps the same seven endpoints as tools for AI agents, with the same limits, because it calls the same API.

There is no endpoint that creates, edits or deletes a QR code. If you are looking for a programmatic way to mint SMS QR codes at scale, the answer today is a QR library in your own backend, as shown above — not a SMLLR API call. Our REST API and MCP server explainer covers the full endpoint list and what each returns.

If the reason you want an SMS QR code is "let the customer contact us in one tap," there is a version of that which is measurable.

Point a dynamic QR code at a landing page that carries the SMS link as a button. The scan hits SMLLR's redirect first — so you get the scan event, the timestamp, the device, the city and the per-code attribution — and the customer then taps through to their messaging app. You lose one tap and gain the entire analytics layer, plus the ability to change the destination number later without reprinting a single flyer.

For many Indian businesses, a WhatsApp CTA is the better destination for that same button, given how much higher WhatsApp engagement runs than SMS domestically. Either way, the principle holds: put the redirect in front of the action, and the campaign becomes measurable.

Create your QR code on SMLLR — choose the SMS type for a direct code, or a dynamic URL code pointing at a page with the SMS link when you need the tracking.