DLT API integration guide
DLT approval is only useful when developers can send the approved payload.
After DLT approval, the practical work shifts to provider API fields, template IDs, sender headers, variable order, delivery reports, retry behavior, logging, and a runbook that support can understand.
SMS gateway API integration after DLT approval is where business compliance work meets production software. The portal may show approved headers and templates, but the application still needs to send the exact approved message pattern through the provider's API.
This guide is for developers, founders, and operations teams wiring OTPs, order alerts, reminders, and service notifications into an app after DLT registration.
API handoff standard
Quick answer
After DLT approval, build a payload map before writing production code.
A developer handoff should include:
- SMS provider account and API documentation.
- Approved sender header for each message.
- Content template ID for each message.
- PE ID or other DLT identifiers required by the provider.
- Variable order and allowed value examples.
- Sample request and response using dummy data.
- Delivery report webhook details.
- Retry, timeout, and failure-handling rules.
- Change control for template wording and IDs.
What developers need after DLT approval
Developers need more than screenshots. They need a deterministic contract.
| Input | Why it matters |
|---|---|
| Provider credentials | Required to authenticate the API call. Store securely, not in documents. |
| Sender header | Controls sender identity and must match the approved DLT asset. |
| Template ID | Connects the message body to the approved content template. |
| Variable order | Prevents values from landing in the wrong placeholder. |
| PE or entity identifiers | Required by some provider APIs or DLT mappings. |
| DLR endpoint | Lets the system receive delivery status and failure details. |
| Test cases | Confirms production behavior before customer traffic. |
If any row is missing, the integration may work in a sandbox but fail during live sending.
Payload mapping model
Provider APIs differ, so do not copy field names blindly. Create a provider-specific payload map.
DLT SMS API payload worksheet
| Concept | Example field name | Example dummy value | Notes |
|---|---|---|---|
| Recipient | to | 919999999999 | Use real test numbers only in private test plans. |
| Sender | sender | ABCOTP | Must match approved header. |
| Template | template_id | TMP-XXXX-7754 | Store with message event name. |
| Variables | variables | ["123456", "5"] | Order must match template placeholders. |
| Entity | pe_id | PE-XXXX-1420 | Provider-specific requirement. |
| Callback | callback_url | /api/sms/dlr | Validate signatures if provider supports them. |
Never commit API keys or provider secrets into source code. Use environment variables or secret storage aligned with the hosting setup.
Delivery reports, retries, and logs
SMS integration should not stop after a 200 OK provider response. The provider may accept a request and later return a failed delivery status.
DLR and failure-handling checklist
- Store provider message ID for correlation.
- Receive delivery report callbacks where supported.
- Validate callback authenticity if the provider documents a signature or token flow.
- Separate API submission failure from network delivery failure.
- Define retry rules for transient provider errors.
- Avoid retrying blindly when the template, header, or DLT mapping is invalid.
- Log enough context to debug without storing sensitive OTP values.
- Alert operations when failure rates cross a threshold.
For OTP flows, be especially careful with retries. A user should not receive multiple valid codes out of order without the application understanding which one is current.
Go-live test plan
Before production, test each approved template:
Static mapping review
Compare the approved portal template, the handover sheet, and the provider payload fields. The names should line up.
Controlled send
Send to internal test numbers only. Confirm sender display, message body, variables, and provider response.
Delivery report check
Verify the callback, status mapping, logs, and failure handling.
Runbook handover
Document how to add a new template, rotate provider keys, debug failures, and request support.
Common API integration mistakes
Hardcoding template IDs without names
IDs should be tied to message event names. Otherwise, nobody knows which ID belongs to login OTP, order update, or appointment reminder.
Changing approved wording in code
Developers may add copy for better UX, but production SMS should match the approved template pattern.
Ignoring delivery reports
Accepted API requests are not the same as delivered messages. Track provider delivery status.
Logging secrets or OTP values
Logs should help debug routing and status without exposing credentials, customer records, or sensitive codes.
FAQ
Can the SMS API be integrated before DLT approval?
You can scaffold the provider client earlier, but production payloads should use approved headers, template IDs, variable order, and current provider requirements.
What happens if the template wording changes?
Treat it as a production change. Review DLT impact, update provider mapping, retest, and update the runbook before live use.
Should OTP values be stored in SMS logs?
Avoid storing sensitive OTP values in logs. Store correlation IDs and status details needed for debugging without leaking codes.
Can Shinka help with DLT API integration?
Yes. Shinka can map approved DLT assets into provider API fields, create sample payloads, test sends, and document the final handoff.
