Preparing for DLT, end to end

Registration runs outside Connect, with the telecom operators, in a fixed order: the entity first, then a header under it, then a template under that. Connect's part begins only at the end, when the granted values are recorded at #/dlt so messages can be composed against them. Nothing on that screen applies for anything, and no registration removes the separate problem that the live carrier carries no SMS.

Status: Foundation In development What this means
Audience: both
Channels: sms
In the app: #/dlt, #/calls
Last verified: 2026-09-10
Product version: 6.3.2

The chain#

Trigger — a business decides it needs to send commercial SMS to Indian subscribers.
User event — somebody in that business gathers the legal identity documents the operator's platform asks for. This is paperwork about the company, not about Connect.
Authentication and workspace resolution — the eventual record belongs to one workspace. Registrations are per business, and the values must be entered in the workspace that will send under them.
Request — entity registration is submitted to the operator's DLT platform. Until it is granted there is nothing to hang a header on.
Canonical record — once entity registration is granted, the identifier is the anchor everything later refers to.
Classification — the business decides what kind of traffic it will send. Transactional and promotional traffic are treated differently, and the answer shapes which headers are worth requesting.
Knowledge and rules — the message copy is drafted to fit what a template allows: fixed wording with the variable parts marked, rather than free prose to be assembled later.
Approval — the operator reviews each request. This is the stage with a waiting time nobody in Connect controls, and it is where most of the elapsed time goes.
Action — headers and templates are registered under the entity, each one granted or refused on its own merits.
Result — the granted header and template values are recorded at #/dlt, where dlt.py holds the registration data for the workspace.
Relationship and memory — nothing about a person changes here. Registration is about the sender, not the recipient, and consent remains a separate obligation enforced by suppression.
Audit and usage — the record of what is registered is the workspace's own; a message composed against a template can be checked against what was granted.
Next — with registrations in hand, sending still requires a provider that carries SMS. The two conditions are independent, and the live carrier satisfies neither.

What to gather before starting#

The legal identity of the business as the operator's platform expects it — the name registrations will be granted against, not a trading name used informally.
A decision about traffic type, because a header granted for one kind of message is not a header you may use for another.
The sender identifier you want recipients to see, with alternatives, since a preferred header may already be taken or refused.
Draft message wording for every message you intend to send, with the variable parts identified — a template is registered as a shape, not as a single message.
A named person inside the business who owns the process, because the operator's review corresponds with the applicant rather than with a platform.

Where Connect participates, and where it does not#

Step	Done where	Connect's part
Gathering identity documents	Inside the business	None
Entity registration	The operator's DLT platform	None — it cannot apply on your behalf
Header request and grant	The operator's platform	Stores the granted header
Template drafting	Inside the business	Knowledge can hold the agreed wording, like any other business fact
Template registration	The operator's platform	Stores the granted template and its variables
Recording the result	`#/dlt`	This is the whole of it
Sending under the registration	A provider that carries SMS	Unavailable on the live carrier

Reading that table downwards is the fastest cure for the most common misunderstanding about this screen. #/dlt is a record, not an application. A workspace with every field filled in and no grants behind them has documented an intention, not a permission.

What can go wrong#

The header is refused: Usually because it is taken, or does not correspond recognisably to the registered entity. Have alternatives ready before you ask.
Templates do not match live messages: The registered shape and the message actually composed have drifted. The operator rejects the traffic; nothing in Connect can absorb that.
Registration is granted to the wrong entity: A group company registered instead of the sending one. This is expensive to unwind and worth checking before submission rather than after.
Everything is registered and nothing sends: The other condition is unmet. Registration and carriage are separate, and the live carrier carries no SMS at all.

Questions#

How long does registration take?

The waiting time belongs to the operators and is not something this documentation can state accurately or usefully. Plan for it as an external dependency with its own schedule, and start it in parallel with the provider question rather than after it.

Do I need a separate registration per workspace?

Registration belongs to the business, not to a workspace. What is per workspace is the record of it: the granted values are entered where the sending would happen, and each workspace's data is scoped to itself like every other record here.

Is DLT needed to receive text messages?

No. Inbound handling, deduplication, attaching a message to a person and honouring an opt-out are the parts of SMS that work today, and none of them is gated by a sender registration.