{"id":652,"date":"2026-10-10T16:55:48","date_gmt":"2026-10-10T11:25:48","guid":{"rendered":"https:\/\/smppcenter.com\/journal\/?p=652"},"modified":"2026-10-10T16:55:50","modified_gmt":"2026-10-10T11:25:50","slug":"trai-url-apk-callback-number-whitelisting-content-templates","status":"publish","type":"post","link":"https:\/\/smppcenter.com\/journal\/trai-url-apk-callback-number-whitelisting-content-templates\/","title":{"rendered":"TRAI URL, APK and Callback Number Whitelisting: What Every SMS Template Actually Needs"},"content":{"rendered":"\n

TRAI’s whitelisting rules block any SMS that carries a URL, APK link, OTT link or callback number that wasn’t pre-registered with your telecom operator. Here’s what gets whitelisted, how the submission actually works, and where it sits next to DLT template registration.<\/p>\n\n\n\n

\"Illustration
Only pre-registered URLs, APKs, OTT links and callback numbers clear the gate once TRAI’s whitelisting rules apply to a template.<\/figcaption><\/figure>\n\n\n\n

Table of Contents<\/h2>\n\n\n\n
    \n
  1. The Short Answer<\/a><\/li>\n\n\n\n
  2. TL;DR<\/a><\/li>\n\n\n\n
  3. What TRAI Mandated, and When<\/a><\/li>\n\n\n\n
  4. The Four Things You Whitelist<\/a><\/li>\n\n\n\n
  5. Whitelisting vs. DLT Template Registration<\/a><\/li>\n\n\n\n
  6. The Submission Process, Operator by Operator<\/a><\/li>\n\n\n\n
  7. What Happens If You Don’t Whitelist<\/a><\/li>\n\n\n\n
  8. Shortened Links and the Smart Link Question<\/a><\/li>\n\n\n\n
  9. Where This Sits in SMPPCenter’s API Surface<\/a><\/li>\n\n\n\n
  10. A Whitelisting Checklist for Aggregators and Resellers<\/a><\/li>\n\n\n\n
  11. Next Steps<\/a><\/li>\n\n\n\n
  12. FAQs<\/a><\/li>\n<\/ol>\n\n\n\n

    The Short Answer<\/h2>\n\n\n\n

    If your SMS template includes a link, an app download link, a WhatsApp or OTT redirect, or a callback phone number, that specific item has to be pre-registered with your telecom operator before it can go out, or the message gets blocked. This isn’t part of the older DLT template approval process. It’s a separate layer that sits on top of it, run operator by operator rather than through one central portal, and it’s been mandatory for URLs, APKs and OTT links since October 1, 2024. A newer direction from November 2025 adds a pre-tagging requirement on top: every variable in a template now has to be labeled with what kind of content it holds, so operators can actually check the whitelist against what gets filled in at send time.<\/p>\n\n\n\n

    TL;DR<\/h2>\n\n\n\n

    Four things need separate whitelisting: URLs, APK links, OTT\/app-redirect links, and callback numbers. You submit them through your DLT operator’s own portal (Jio, Vi, Airtel, BSNL, Tata and the rest each run this slightly differently), not through a single TRAI system. Since October 1, 2024, there’s no grace period for non-whitelisted URLs, APKs or OTT links. A follow-up TRAI direction issued November 18, 2025 requires template variables to carry a tag like #url#<\/code>, #cbn#<\/code> or #numeric#<\/code> so operators can validate what’s actually being inserted, with a 60-day window before non-compliant templates start getting rejected outright. None of this replaces DLT template or header registration; it’s an additional check that runs on top of it.<\/p>\n\n\n\n

    \n\n\n\n

    What TRAI Mandated, and When<\/h2>\n\n\n\n

    TRAI’s direction on this dates to August 20, 2024. The stated reason was a rise in SMS-based phishing, fake delivery notifications, fraudulent app downloads, and scam links riding on otherwise legitimate, DLT-approved sender headers. The fix TRAI landed on was to stop treating a template’s approval as covering everything inside it. A template could be approved with its fixed wording intact, and still carry a completely different, unregistered URL by the time it actually reached a phone.<\/p>\n\n\n\n

    The original compliance date got pushed back once. TRAI’s press release (PR No. 60 of 2024)<\/a> confirms access providers asked for more time, and TRAI granted a one-month extension, moving the cutoff to October 1, 2024. From that date, telecom operators stopped accepting SMS traffic containing a URL, APK link or OTT link that wasn’t already whitelisted. Callback numbers were carved out of that first deadline. TRAI said a revised timeline for callback numbers would come separately, and it did, bundled into the newer rule below.<\/p>\n\n\n\n

    That newer rule is TRAI’s direction of November 18, 2025 (PR No. 133 of 2025<\/a>), and it closes a gap in the first round. Whitelisting URLs and callback numbers only works if the operator can actually tell which part of a message is the variable part. A template’s fixed text might say “Your OTP is” and then insert a number, or “Click here:” and then insert a link, but nothing forced senders to label which placeholder held what. The 2025 direction requires every variable in a content template to carry a tag indicating its type: #number#<\/code> or #numeric#<\/code> for digits only, #url#<\/code> for a standard link, #urlott#<\/code> for an app-download or OTT redirect link, #cbn#<\/code> for a callback number, #email#<\/code> for an email address, and #alphanumeric#<\/code> for mixed-character values like booking references, capped at 40 characters. Templates generally carry up to two such variables, with a third allowed in exceptional cases and anything beyond that needing a business justification.<\/p>\n\n\n\n

    Access providers and principal entities have 60 days from the direction to bring existing templates into line. After that window, a template that doesn’t tag its variables correctly, or that gets filled with content that doesn’t match its tag (a #numeric#<\/code> field populated with letters, for instance), starts getting rejected rather than flagged. That’s a meaningful change from the first round, where operators were told to block outright from day one. Here there’s at least a runway to fix templates before enforcement kicks in, which matters if you’re managing a large template library across multiple principal entities.<\/p>\n\n\n\n

    \n\n\n\n

    The Four Things You Whitelist<\/h2>\n\n\n\n

    Each category has its own format rules, and getting the sub-type wrong is a common reason a whitelisting submission gets rejected.<\/p>\n\n\n\n

    URLs.<\/strong> These split into static and dynamic. A static URL starts with http<\/code>, https<\/code> or www<\/code> and has no query string. A dynamic URL follows the same pattern but ends in a ?<\/code>, which signals that parameters get appended at send time (a tracking ID, a recipient-specific code, that sort of thing). Static and dynamic URLs are whitelisted as separate sub-types even if they share the same base domain.<\/p>\n\n\n\n

    APK links.<\/strong> Same http<\/code>\/https<\/code>\/www<\/code> prefix rule, but the link has to end in .apk<\/code>. This is specifically for direct app-download links, not app store links (a Play Store or App Store URL is just a regular URL for whitelisting purposes).<\/p>\n\n\n\n

    OTT and app-redirect links.<\/strong> These cover links that open WhatsApp, Telegram or similar apps directly, sometimes called WABA links in operator documentation. They’re whitelisted separately from a standard URL even when they resolve through a similar domain pattern.<\/p>\n\n\n\n

    Callback numbers.<\/strong> These split further by number type: a 10-digit mobile number starting with 6 through 9, with or without the 91 country prefix; a landline number, 10 digits with or without a leading 0; a toll-free number starting with 1800 or 1860, 8 to 11 digits; and a 140 or 160-series number (used for promotional and service calls respectively), which has to be exactly 10 digits.<\/p>\n\n\n\n

    Email addresses get a tag under the 2025 pre-tagging rule too, but TRAI’s original CTA whitelisting direction didn’t require separate email pre-registration the way it did for the other four categories. Treat the email tag as a variable-labeling requirement rather than a whitelisting one.<\/p>\n\n\n\n

    \n\n\n\n

    Whitelisting vs. DLT Template Registration<\/h2>\n\n\n\n

    It’s worth being precise about what CTA whitelisting is not. It’s not the same step as registering a header or a content template under TCCCPR 2018, and getting a template approved on the DLT platform doesn’t automatically whitelist anything inside it. DLT template approval checks that the fixed wording and category (promotional, transactional, or service) are consistent and match what’s registered to your principal entity. CTA whitelisting is a second, independent check that runs against the variable content once a message is actually queued for delivery, specifically on whether any URL, APK link, OTT link or callback number in that variable slot has been separately pre-approved.<\/p>\n\n\n\n

    That distinction matters operationally because the two processes run on different timelines and, in practice, through different workflows even when they technically sit on the same operator portal. A principal entity can have a perfectly valid, approved template and still have messages blocked because the URL being inserted at send time was swapped for a new one that was never whitelisted. This is exactly the scenario TRAI was targeting: fraud actors weren’t forging templates, they were slipping new destinations into the variable part of templates that were already approved.<\/p>\n\n\n\n

    TCCCPR 2018’s underlying structure, including how a Principal Entity registers once and then has to bind a telemarketer into an approved PE-TM chain before traffic from that chain is accepted, is a separate layer again, and the two aren’t interchangeable. Getting your PE-TM chain approved doesn’t whitelist your URLs, and whitelisting your URLs doesn’t substitute for chain approval. If your traffic is getting blocked, it helps to know which of the three systems is actually rejecting it: template\/header registration, PE-TM chain binding, or CTA whitelisting. They fail differently and get fixed through different portals.<\/p>\n\n\n\n

    Consent filtering against India’s do-not-call registry is a fourth, unrelated system entirely. NCPR scrubbing checks whether a recipient opted out of promotional contact; CTA whitelisting checks whether the content inside an approved message is itself pre-registered. A message can pass NCPR scrubbing cleanly and still get blocked on an unwhitelisted link, and vice versa.<\/p>\n\n\n\n

    \n\n\n\n

    The Submission Process, Operator by Operator<\/h2>\n\n\n\n

    There’s no single TRAI-run portal where you submit a URL or callback number once and it’s whitelisted everywhere. Each access provider runs its own DLT platform and publishes its own CTA whitelisting procedure: Jio’s TrueConnect, Vi’s VIL Power, Airtel’s DLT portal, along with Tata’s and BSNL’s own systems. The fields are broadly similar across operators even though the portals look different. You’re typically asked for a CTA Name (a label for your own reference), a CTA Type (URL or number), a CTA Sub-Type (static URL, dynamic URL, APK, mobile, landline, toll-free, and so on), and the CTA Input itself, validated against the format rules above.<\/p>\n\n\n\n

    None of the operator guidance we found states a fixed turnaround time for CTA approval the way some of them do for principal entity registration (which is commonly cited around two to three days). Treat any specific hour or day figure you see quoted for CTA whitelisting with some skepticism unless it comes from your own operator’s documentation, since we couldn’t confirm a consistent, published SLA across operators for this specific step.<\/p>\n\n\n\n

    A practical wrinkle for anyone running campaigns across more than one carrier: whitelisting on Jio doesn’t carry over to Vi, and vice versa. If your traffic fans out across multiple operators, which is normal for any aggregator sending at volume, the same URL or callback number needs submitting on each operator’s portal separately. This is one of the more common sources of partial delivery failures: a campaign that lands fine on three carriers and silently fails on the fourth because that one operator’s whitelist entry was never submitted.<\/p>\n\n\n\n

    \n\n\n\n

    What Happens If You Don’t Whitelist<\/h2>\n\n\n\n

    For URLs, APKs and OTT links, there’s been no grace period since October 1, 2024. A message carrying an unwhitelisted link in that category gets blocked at the operator level, not flagged for later review. TRAI’s direction was explicit that access providers were not to permit this traffic at all past that date.<\/p>\n\n\n\n

    The 2025 pre-tagging direction runs on a different enforcement curve. Access providers and principal entities have 60 days from the direction to update templates with the correct variable tags. During that window, the expectation is that non-compliant templates get identified and corrected rather than blocked outright. Once the window closes, a template whose tags don’t match what’s actually being sent (an untagged URL variable, or a #numeric#<\/code> field that gets filled with non-numeric content) moves to rejection.<\/p>\n\n\n\n

    The practical effect for anyone running templates at scale is that a previously reliable template can start failing without any code change on your side, simply because an operator’s enforcement of either rule tightened on a date you weren’t tracking. That’s a strong argument for treating CTA whitelisting and template tagging as an operational checklist item with its own owner, not a one-time setup task done at onboarding and then forgotten.<\/p>\n\n\n\n

    \n\n\n\n

    Shortened Links and the Smart Link Question<\/h2>\n\n\n\n

    Link shorteners complicate whitelisting in a specific way worth flagging. If a template’s URL variable gets rewritten into a short link before delivery, whichever system checks the whitelist has to be checking the right thing: either the shortener’s own domain (whitelisted once) or the final destination (which would mean re-whitelisting every time the destination changes). Industry practice among SMS platforms that offer their own shortener generally leans toward whitelisting the shortener’s domain itself, rather than treating every shortened link as a brand-new URL needing separate approval, though the exact mechanics differ by platform and by operator.<\/p>\n\n\n\n

    SMPPCenter’s own Smart Link plugin<\/a> shortens URLs for SMS campaigns, converts links in attached files automatically, and tracks visitor data per click. What SMPPCenter’s own documentation doesn’t currently state is how a Smart Link-shortened URL is meant to interact with CTA whitelisting on the receiving operator’s side, whether the practical approach is to whitelist Smart Link’s shortening domain once, or whether each destination still needs separate operator-side approval. If you’re using Smart Link in a template that also needs to clear CTA whitelisting, that’s a question worth putting directly to SMPPCenter support before you rely on it in production, rather than assuming either answer.<\/p>\n\n\n\n

    \n\n\n\n

    Where This Sits in SMPPCenter’s API Surface<\/h2>\n\n\n\n

    SMPPCenter’s documented API categories<\/a> include a Message Template category (create, read, update, delete) and a separate Sender ID category with the same four operations. Neither category’s public listing names a DLT status field, a whitelisting state, or any flag indicating whether a given template’s variables have been tagged or whether a URL or number referenced in that template has cleared operator-side whitelisting. That’s not unusual; a lot of platforms treat whitelisting as something that happens on the operator’s DLT portal directly, outside the sending platform’s own API surface, and SMPPCenter’s public documentation doesn’t contradict that reading. It does mean the practical whitelisting workflow, submitting CTA entries, checking their approval status, tagging variables correctly, currently runs through the operator portals described above rather than through anything exposed in SMPPCenter’s own API.<\/p>\n\n\n\n

    DLT template matching is referenced on SMPPCenter’s DPDP compliance page<\/a> as something built into message validation, checking that an outgoing message matches a pre-approved, consented template before it’s queued. That’s a related but distinct check from CTA whitelisting: template matching confirms the message matches what was registered, while CTA whitelisting confirms the specific link or number inside it has independently cleared the operator’s whitelist. A message can pass one and fail the other.<\/p>\n\n\n\n

    \n\n\n\n

    A Whitelisting Checklist for Aggregators and Resellers<\/h2>\n\n\n\n

    For anyone managing multiple principal entities or a reseller downline, a few habits avoid most of the actual failure cases:<\/p>\n\n\n\n