Sender ID and template setup

Headers and templates, briefly

A header is the short sender name at the start of the message — for transactional-style traffic it is alphabetic (the homepage's safe API example uses SMPLID as a sample sender). Promotional traffic uses the numeric header series assigned on DLT instead.

A template is the approved message content. Where a message carries variable data — an OTP code, an order number, an appointment time — the template declares those as variables, and your application fills them in at send time. The homepage example references a template by name (order_shipped_v3); your registered template ids are what your sends will reference.

Registration steps

1. Entity approved firstHeaders and templates are registered against your approved entity. If entity approval is still in progress, finish that first — see DLT registration for Indian business SMS.
2. Register your headersRegister the sender names you will actually use. Plan them once: a small, consistent set of headers is easier to get approved and easier to keep clean than many variants.
3. Register templates with variables declaredWrite templates with the variable positions declared, one template per distinct message purpose — an OTP template, an order-shipped template, and so on.
4. Track approvals in the portalThe sms-ocean admin portal's DLT approvals page shows where each approval stands, so onboarding and your team look at the same status.
5. Send with the approved values onlyWhen you integrate, reference the approved header and template — not paraphrased versions. The template id and header you send with must be the ones DLT approved.

Why sends get rejected at the content check

The habit that prevents all four: treat the approved template as the single source of copy. Change the template on DLT first, then change the application — never the other way round.

• Wording drift — the application sends copy that no longer matches the approved template after a product or marketing change.
• Variable mismatch — values inserted in a different order or count than the template declares.
• Header mismatch — sending with a header the template is not registered against.
• Category mismatch — promotional content sent under a transactional-style header, or the reverse.

Different jobs, different setup

The homepage's choose-a-job cards state the eligibility plainly: OTP delivery needs your business entity and OTP templates registered on DLT; a transactional update needs the entity, sender ID and message templates approved for transactional use; a permitted campaign needs promotional headers and templates, and content sent only to opted-in recipients.

Whichever job you start with, the setup order is the same: entity, then header, then template, then send. The template's declared variables and the header it is registered against are the two values your integration must mirror exactly.

Frequently asked questions

Next step

Create your account and start the workflow this guide covers — where a step is managed by our team rather than self-serve, we say so during signup. Prefer to talk first? Contact us and we will walk through it with you.