SMS Delivery Webhooks: Track Delivered, Failed & Pending

Sending SMS is only half the job. Your app needs to know whether the message was delivered, rejected, or still pending — especially for OTP, payment alerts, and order updates. SplitSMS pushes signed delivery webhooks to your HTTPS endpoint as status changes.

Instead of polling message IDs, store the provider message reference when you send, then update your row when the webhook arrives. That pattern scales for bulk campaigns and transactional flows alike.

Typical payloads include message ID, destination, status (delivered, failed, pending), timestamp, and an error reason when something went wrong (invalid number, blocked Sender ID, insufficient balance).

Verify the webhook signature before you trust the body. Reject unsigned or mismatched requests so attackers cannot forge “delivered” events into your system.

Respond with HTTP 200 quickly, then process asynchronously if your work is heavy. SplitSMS may retry on non-2xx responses — make handlers idempotent so duplicate events do not double-credit or double-notify.

Map statuses into your UI: green for delivered, amber for pending, red for failed with a human-readable reason. Support teams will thank you when a customer asks “did my OTP arrive?”

Create an API key, set your webhook URL in the developer settings, and send a test SMS to your phone. Watch Dashboard → API logs and your server logs together until the flow is solid.

Full request shapes live in the SplitSMS API docs and Postman collection — start there, then wire production URLs behind HTTPS only.