DLT template approval guide
A DLT template should describe exactly what your app will send.
Template approval gets messy when teams hide changing copy inside variables, mix marketing with OTPs, or submit content before the business event is clear. Cleaner templates start with message intent, consent context, fixed wording, and developer payload mapping.
DLT template registration is where many SMS projects slow down. Entity registration may be complete. Header approval may be done. The SMS provider may be ready. Then the content template is rejected, unclear, too broad, or impossible for developers to send without changing the wording.
This guide explains how to prepare DLT templates with a practical implementation lens: choose the right message category, separate consent and content decisions, write stable message copy, keep variables narrow, prepare clean samples, and map approved templates into the SMS API.
Official source note: TRAI lists content template registration and consent registration as part of the sender workflow. Airtel also publishes content template guideline material for its commercial communication platform. Always check the current portal instructions before submission: TRAI Advice to Senders.
Template approval depends on clarity
Quick answer
DLT template approval is easier when the message is specific and production-ready.
Before submitting a DLT template, confirm:
- The business event that triggers the SMS.
- The sender header that will send it.
- Whether the message is OTP, service implicit, service explicit, or promotional.
- Whether customer consent is required for this flow.
- The exact fixed message text.
- The variables and what each variable is allowed to contain.
- The provider API fields and sample payload.
- The rule for changing wording after approval.
Content template versus consent template
A content template and a consent template are related but not interchangeable.
| Template type | What it describes | Example planning question |
|---|---|---|
| Consent template | Why and how permission is acquired where applicable | "Has the customer explicitly agreed to receive appointment reminders or offers?" |
| Content template | The recurring SMS body sent through the provider | "What exact wording and variables will the app send?" |
For OTP and triggered service alerts, teams often focus on content templates. For explicit-consent communication or promotional flows, consent handling becomes a larger operational question. The exact route should be confirmed with the current operator portal and provider guidance.
Variable discipline
Variables are useful only when they are narrow. A good variable changes a value without changing the meaning of the message.
Variable quality examples
| Use case | Better variable | Risky variable |
|---|---|---|
| OTP | code, expiry_minutes | Full sentence with code and offer copy. |
| Order update | order_id, status, tracking_link | Entire status paragraph in one placeholder. |
| Appointment reminder | doctor_name, date, time | Generic reminder text replaced every time. |
| Payment receipt | amount, invoice_id, short_link | Mixed receipt and campaign message. |
If a variable can hold anything, reviewers and future developers cannot know what the message really is. Keep fixed business language outside variables and use variables only for values that genuinely change per recipient.
Template review worksheet
Use a worksheet before portal submission:
DLT template readiness checklist
- Message event is documented.
- Sender header is selected.
- Category is chosen before copy is written.
- Fixed wording is final or very close to final.
- Variables are named and explained.
- Sample values are dummy and realistic.
- Consent relationship is recorded where applicable.
- Links, APK references, phone numbers, and URLs are reviewed for additional provider requirements.
- Developer payload fields are identified.
- The business owner signs off on final wording.
Do not submit "temporary" copy unless everyone understands that production code may need to wait for the final approved version.
Common rejection patterns
Mixed intent
The template starts as an OTP or service alert but includes offers, broad promotional language, or unrelated nudges.
Weak brand relationship
The content references a brand, product, or sender name that does not clearly connect to the registered entity or header.
Overbroad variable
A variable hides full sentences, campaign copy, or changing claims. This makes the approved template unpredictable.
Consent ambiguity
The message implies consent-based communication, but the consent template, purpose, or customer journey is not documented.
What to do after approval
Template approval is not the end of the work. The approved template must be translated into production behavior.
Record the approved template ID
Store it with the header, category, message event, and portal notes. Mask sensitive IDs in public screenshots.
Map variables to the API payload
Developers need the variable order, allowed values, and example request body using dummy data.
Run controlled tests
Send test SMS for each template and compare received text against approved wording.
Create a change policy
Any content change should be reviewed for DLT impact before it reaches production.
FAQ
Can I change SMS wording after a DLT template is approved?
Treat wording changes carefully. If the production message no longer matches the approved pattern, it may need review, resubmission, provider updates, and retesting.
Can a variable contain a full sentence?
Avoid that. Variables should hold narrow values, not changing message intent. Full-sentence variables are harder to review and maintain.
Do all templates need a consent template?
Not always in the same way. The need depends on message category, consent path, and current portal/provider rules. Document the decision before submission.
Can Shinka review existing rejected templates?
Yes. Shinka can review the wording, variables, category fit, consent context, and API mapping before resubmission. Approval remains controlled by the operator process.
