{"id":3035,"date":"2026-09-23T12:06:55","date_gmt":"2026-09-23T06:36:55","guid":{"rendered":"https:\/\/www.smsgatewaycenter.com\/blog\/?p=3035"},"modified":"2026-09-23T12:09:36","modified_gmt":"2026-09-23T06:39:36","slug":"message-template-management-four-channels","status":"publish","type":"post","link":"https:\/\/www.smsgatewaycenter.com\/blog\/message-template-management-four-channels\/","title":{"rendered":"Message Template Management Across SMS, RCS, WhatsApp and Telegram: One API Comparison"},"content":{"rendered":"\n

Four channels, five placeholder spellings, four identity models and three approval shapes. A field-by-field comparison of the SMS DLT, RCS, WhatsApp and Telegram template endpoints, with a portable registry schema, safe rendering code in four languages and a change workflow that survives approval delays.<\/p>\n\n\n\n

\"Four<\/a>
Four channels, four template models, one stable key of your own that maps to all of them<\/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. Four Template Models at a Glance<\/a><\/li>\n\n\n\n
  4. What a Template Actually Is on Each Channel<\/a><\/li>\n\n\n\n
  5. Placeholder Syntax: Five Spellings, No Shared Code<\/a><\/li>\n\n\n\n
  6. Who Renders the Variables<\/a><\/li>\n\n\n\n
  7. The SMS Template Lifecycle Over the API<\/a><\/li>\n\n\n\n
  8. DLT Variable Tags and What They Change in Your Code<\/a><\/li>\n\n\n\n
  9. Validating an SMS Body Before You Send<\/a><\/li>\n\n\n\n
  10. The RCS Template Lifecycle<\/a><\/li>\n\n\n\n
  11. The WhatsApp Template Lifecycle<\/a><\/li>\n\n\n\n
  12. The Telegram Template Model<\/a><\/li>\n\n\n\n
  13. Identity: Why an Edit Is a New Template<\/a><\/li>\n\n\n\n
  14. Approval State: A String, an Integer, Two Fields or Nothing<\/a><\/li>\n\n\n\n
  15. Response Envelopes Across the Template Endpoints<\/a><\/li>\n\n\n\n
  16. A Portable Template Registry Schema<\/a><\/li>\n\n\n\n
  17. Rendering Safely in Four Languages<\/a><\/li>\n\n\n\n
  18. The Template Change Workflow<\/a><\/li>\n\n\n\n
  19. Ten Template Mistakes That Reach Production<\/a><\/li>\n\n\n\n
  20. Decision Matrix<\/a><\/li>\n\n\n\n
  21. Pre-Launch Checklist<\/a><\/li>\n\n\n\n
  22. Unspecified Behaviour and How to Code Around It<\/a><\/li>\n\n\n\n
  23. FAQs<\/a><\/li>\n<\/ol>\n\n\n\n

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

    You cannot manage SMS, RCS, WhatsApp and Telegram templates with one piece of code, because the four channels disagree on every property that matters. They use five different placeholder spellings (DLT typed tags such as {#numeric#}<\/code>, the legacy DLT {#var#}<\/code>, RCS [name]<\/code>, WhatsApp {{1}}<\/code> and Telegram {name}<\/code>). They identify a template four different ways (a local mtId<\/code> plus a regulator dltTemplateId<\/code>, an RCS name<\/code>, a WhatsApp name plus language pair, and a Telegram integer templateId<\/code>). They report approval as a string, an integer, two independent string fields, or not at all. And only SMS has an update endpoint; on RCS and WhatsApp an edit is a delete and a recreate, and on SMS a re-tagged DLT template comes back with a new DLT Template ID anyway.<\/p>\n\n\n\n

    The design that works on all four is simple to state: key your own system on a stable template identifier you own, store every provider identity as a versioned row beneath it, render variables with a tokenizer rather than a regex replace, gate sending on an approval state you normalise yourself, and never retire an old version until every scheduled send that references it has drained.<\/p>\n\n\n\n

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