Skip to main content

​
Troubleshoot India DLT gate 422 rejects

India’s TRAI DLT (Distributed Ledger Technology) regime routes every A2P SMS through pre-registered content templates. Orbit’s India DLT gates run before the send is submitted and reject a violation with 422 MESSAGING_IN_DLT_TEMPLATE_REQUIRED (no template id at all) or 422 MESSAGING_IN_DLT_CONTENT_MISMATCH (template id present, but the body or sender does not match your registered template). Read the code out of the response before retrying — a blind retry re-burns the same reject. The gates are tenant-owned controls: they run only on India-bound destinations and only when your organization has opted in via the regional send-gates toggle (see [Gate scope](#gate-scope-the-toggle-and- environments)). Enabling them moves the reject from the carrier’s DLR back to your API response — carriers drop unregistered or mismatched traffic at the DLT scrubbing function either way, and a carrier drop still charges your wallet.

​
Symptom: a 422 on an India-bound send

A send to an Indian destination (+91…) returns HTTP 422 with one of:
or:
The first code means the request carried no template id. The second means the request carried one, but the message body or sender does not match the content template that id was recorded under. The fix differs — read details.mismatch_type (body or sender_header) before you retry.

​
Field rules: the template id is required on every India send

India gates expect a DLT template id on every India-bound send. Supply it in either shape — the gate accepts both:
or nested:
A missing, empty, or whitespace-only value trips MESSAGING_IN_DLT_TEMPLATE_REQUIRED. A non-empty string passes the presence gate; the content match runs only when you have also recorded that template id locally as an approved content template (next section). Full send examples are on SMS channel; the metadata field rides in the same request as to, from, and body.

​
Content mismatch: body and sender must match the registered template

Once a template id is recorded in your tenant’s DLT registry with approved status, second-layer enforcement compares the full send against the recorded template: Match is anchored and case-insensitive: extra leading or trailing content fails, but whitespace drift (newlines, double spaces) is normalized on both sides, so formatting differences between compose surfaces do not read as a mismatch.

​
Approving a new template version

If the new wording is genuinely what you want to send, do not fight the gate around it — secure the new content through your DLT registrar’s portal, then record the approved version in your tenant’s DLT registry via the DLT-India registration endpoints (content templates; the template id updates on the send). Sends with the new id pass as soon as the recorded row reaches approved status. The gate fails open when it cannot match locally: a template id with no approved record in your tenant (registered out-of-band with the registrar), or a tenant whose DLT tables are not yet provisioned, passes on the id-presence check alone.

​
Where to find your approved template id

Your approved template id comes from the DLT registrar’s portal you registered on. Record it — together with the header (Sender ID) and the principal entity it belongs to — in your tenant’s compliance registry so the gate can match your sends against it:
  • The dashboard compliance surface: /compliance/dlt-india.
  • The API surface: the DLT-India registration endpoints under /api/v1/compliance/dlt-india — record content templates and read their approved status before you trust the id on a send. Full onboarding order (principal entity, headers, content templates, consent templates) is in DLT-India Onboarding.
Sends against a template id we have not recorded as approved still pass the gate (fail-open posture), but Indian carriers will drop the traffic downstream — keep the registry current.

​
Gate scope: the toggle and environments

All India gate probes guard an organization settings key:
  • Path: regional_send_gates.IN.enabled
  • Default: off — India-bound sends are not gate-checked until you opt in.
Flip the key off while you register, or scope it to your production organization and keep a dedicated sandbox organization with the key off so test traffic skips the gate. Flipping it off removes both the missing-id and content-mismatch rejects; carriers still enforce DLT downstream, so enable it back before production volume. To stop an in-flight send loop from burning wallet on guaranteed-fail traffic, prefer keeping the gate on and fixing the request — the gate rejects before any wallet deduction.