DLR Payload Tester
Paste a delivery report row and see how a careful parser would read it: field types, ids that must stay text, the dedupe key and timestamp quirks. Then copy a ready-made cURL command and handler code to test your own webhook endpoint.
1. Payload
Pick a scenario or paste your own row. A single row or an array of rows works.
2. Parser check
What a careful consumer of this row would flag.
| Field | Found | Expected |
|---|
3. Test your endpoint
Send this payload to your own handler from a terminal. Browsers block cross-site posts from a page like this, so the tool builds the command and does not send it.
getDlr report. This tool assumes a pushed webhook row has the same shape, so confirm your account's webhook payload in the developer API docs before you rely on it. Nothing you paste is uploaded or stored.What is a delivery report (DLR)?
A delivery report is the per-message record of what happened after you submitted an SMS: whether it was delivered, failed or is still pending, when the row reached that state, which operator handled it and, for failures, an error code. For group sends and file uploads, the delivery report feed is the only place each recipient appears, so it is worth parsing carefully and storing as a record rather than treating it as a dashboard.
What this tester checks
It compares your row with the 20 documented fields and their types, then flags the things that usually go wrong. uuId is an 18 to 19 digit transaction id, so it has to stay text: parsed as a number it can silently change. mobileNo should be stored as text too. deliveryTime can be slightly earlier than submitTime, so clamp any latency calculation at zero. For failed rows, branch on the numeric globalErrorCode, not on the display text in cause.
A dedupe key that is actually unique
A pushed row can arrive more than once, so you need a key that makes a repeat insert a no-op. msgId is a free-form label and can repeat across unrelated rows, and cursorId is only a paging position. A safe key is uuId + mobileNo + submitTime + status: it keeps each state change as its own row and collapses genuine repeats. The tester shows this key for the row you paste. The full reasoning is in our guide to delivery report ingestion.
Frequently Asked Questions
A DLR (delivery report) is the per-message record of what happened after you submitted an SMS. It shows whether the message was delivered, failed or is still pending, when the row reached that state, which operator handled it and, for failures, an error code.
The uuId is an 18 to 19 digit transaction id. That is larger than the largest integer JavaScript can represent exactly, so a parser that reads it as a number can silently change its value. Keep it as a string and use it as text in your database.
Use uuId, mobileNo, submitTime and status together. The msgId field is a free-form label that can repeat across unrelated rows, and cursorId is only a paging position. Including status keeps each state change as its own row while collapsing genuine repeats.
No. The analysis runs entirely in your browser using JavaScript. Nothing you paste is uploaded or stored. The cURL command is built for you to run yourself against your own endpoint.
No. The tool checks the shape of a row against the documented delivery report fields. The exact payload your account receives, and how to register a webhook, are covered in the developer API documentation, so confirm them there before relying on the result.
Building a DLR integration?
Our developer API covers delivery reports, webhooks and the full send flow, with sample code and a Postman collection.
Read the API docs