Job twilio-sms-notifications-with-delivery-receipts · revised 11 October 2026
Send one kind of SMS notification from your app through Twilio and track its delivery
One agreed app event sends one SMS through your Twilio account, and the app stores each message's delivery status from signed callbacks, even when they arrive out of order.
You might be seeing
- The app logs that it asked Twilio to send, but no record says whether the phone got the text
- Staff cannot tell a number that cannot receive texts from a temporary failure
- A status callback handler, if one exists, sometimes shows a message as sent after it was delivered
No passwords, keys, card details or admin invites needed to start.
What usually happened
Sending an SMS is one API call, but knowing what happened afterwards depends on status callbacks that arrive separately, can arrive out of order, and carry error codes whose meaning the provider says may change. Without a signed, order-tolerant handler and a stored message record, the app cannot show whether a customer was told, and a failed number is retried blindly or forgotten.
Who it’s for: A founder or product owner whose app should text customers about one event, such as an appointment reminder or a dispatched order, and who has a Twilio account with a sending number or messaging service already approved by the account holder.
Usually starts when: Staff are phoning or emailing customers by hand about the event, or a first SMS attempt sends messages but nobody can tell which ones were delivered.
The result: When the agreed event happens, one SMS is sent to the agreed test phone through your Twilio account. The app stores the message SID and updates its status from signed callbacks to a final state, a late older status never overwrites a later one, and an unsigned callback changes nothing.
Check whether this job fits
Answer from what you already know about your Twilio account and app. This is a fit check, not a compliance check, and it needs no credentials.
Checks you can run yourself
Read the status history of one existing message
In your Twilio console, open one message you sent and read its status and any error code. Do not copy the recipient's number into an enquiry.
Look for: Whether it shows delivered, undelivered or failed, and whether an error code is present. Sent without a later delivered status is common and needs the callback record to interpret.
What you get
- A pull request with the send function, the message table, the callback endpoint and tests
- A table of the statuses the app stores and the rule for which can follow which
- Redacted evidence of a live send to your own test phone, with its stored status history
- Undo steps and a note of what the app does with each failure code
Included
- One notification type triggered by one named event in an existing app, sent through Twilio's Programmable Messaging API from your server
- A stored record per message: the Twilio message SID, the recipient reference, the current status, the error code when one is reported and the time of each change
- A status callback endpoint that validates Twilio's request signature with Twilio's own library for your language, then applies a forward-only status rule
- Handling of a failed send request without a retry loop, and a plain-language failure label for the commonest error codes in your admin view
- Tests for the send, the callback ordering rule and the rejected unsigned callback
Not included
- Sender registration or approval for any country: US 10DLC registration, toll-free verification, short codes and alphanumeric sender IDs stay with your account holder
- Buying or porting numbers, billing set-up or cost optimisation
- Receiving replies or handling opt-out keywords; this job sends one way
- Deciding who may be texted or whether you hold consent; the app sends only to numbers your own data marks eligible
- One-time-code verification flows, WhatsApp or RCS
- Any promise that a given handset receives a given message
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
The agreed event on staging sends exactly one SMS to the agreed test phone, which receives it, and the app stores one message record with the message SID.
Evidence: Redacted photo or text of the received message, the stored record and the Twilio message SID for that send.
Callbacks move the stored status forward to a final state, and replaying an older callback after the final one leaves the final state unchanged.
Evidence: Test output replaying a sent callback after a delivered callback, and the stored status history showing the final state kept.
A callback with a missing or wrong signature is rejected and changes no stored record.
Evidence: Test output showing the rejection response and an unchanged record.
With Twilio's documented test credentials, a send to the documented invalid-number test value is recorded as a failed attempt without a crash or a retry loop.
Evidence: The recorded failed attempt with its error code and the log showing exactly one request.
Sign-off. You read the received message, the status history and the test output, then sign off in writing and merge. Payment follows sign-off; your team deploys and holds the production credentials.
If it fails. If the agreed checks do not pass you do not pay for this fixed scope. If the cause is sender approval, carrier filtering or your Twilio account, we explain the evidence and stop. Wider work needs a new written agreement.
When it fits, and when we stop
It fits when
- Your Twilio account already has a sender approved for the countries you will text, confirmed by the account holder
- You can name the one event that triggers the message and the data fields the text will contain
- The app can run a staging copy with a public HTTPS address that Twilio can reach for callbacks
- You have at least one test phone you own, and an authorised person who holds the Twilio credentials and reviews and merges the change
We stop and tell you if
- The sender is not registered or approved for the destination, so carriers block messages whatever the code does
- The callback address cannot be reached over HTTPS from Twilio's side
- The scope turns out to need inbound messages, opt-out handling or several notification types, so we quote a different job
- Nobody on your side can hold the credentials or confirm that the recipients may be texted
What could go wrong
Before merge, closing the pull request changes nothing. After merge, reverting it stops the sends; the message table can be kept for history or dropped under your own retention rules. We make no changes inside your Twilio account.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A real customer is texted during testing. | Testing uses phones you own on staging, and the eligibility check blocks any number your data does not mark as eligible. |
| A forged callback marks a message delivered or failed. | The endpoint validates the request signature, which Twilio computes over the exact URL and the posted form fields, with Twilio's own library before acting on the request, and a test proves an unsigned request changes nothing. |
| The app depends on error codes whose meaning the provider says may change. | Codes are stored and shown as reported, with a plain label only for a few common cases; no business rule branches on an exact code. |
A reviewer separate from the builder checks the diff, the signature validation, that no credential or phone number is logged and that the app sends only to eligible numbers. Your authorised maintainer merges, and you hold the production credentials.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the event, message outline, destination countries, eligibility rule and who holds the credentials
- Read the code that handles the event and find a place for the send that cannot slow the user's request
- Build the send function and message table on a branch, calling Twilio with a status callback address
- Build the callback endpoint with signature validation and a forward-only status rule, with tests that replay callbacks out of order
- Run the test-credential error case, then a live send to your own phone on staging and capture the stored history
- Have an independent reviewer check the diff and evidence, then hand over the pull request with undo steps
An enquiry books nothing and charges nothing. Scope, access route and checks are agreed in writing first.
Need to keep it working?
If texts are important to your customers, ask about the monthly service that reviews failed and undelivered messages and flags numbers that keep failing.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Your developer can follow Twilio's guide to tracking outbound message status and its webhook security guide, which recommend validating signatures with the official library. www.twilio.com
- If you only need one-time verification codes, Twilio's Verify product sends and checks them for you; check whether it fits before commissioning a custom sender. www.twilio.com
Questions
Do you handle US sender registration for me?
No. Registration, consent and the rules for your destination countries stay with your account holder. The job assumes an approved sender and tells you plainly if that is missing.
Why test on my own phone rather than with Twilio's test credentials?
Messages sent with test credentials do not trigger status callbacks, so they cannot show the delivery tracking working. They are used for the error case only.
Can the app reply to customers or handle STOP?
Not in this job. It sends one way. Inbound handling would be agreed separately.
Will every message be reported as delivered?
No promise is made. Twilio notes that handset confirmation applies only where available, so the app stores whatever final status the provider reports.
Send an enquiry
Send us
- The app's language and framework, and the one event that should send the text
- The destination countries and whether your Twilio sender is already approved for them, as a yes or no
- The message wording in outline, with no customer numbers or personal data
- Do not send Twilio credentials, phone lists or code in the first enquiry
Later, once you agree
- Read access to the code through a company-controlled repository or export, and a staging environment you control
- Staging credentials created and held by you, with the account's auth token kept in your secret store and never shared with us
- One or two test phone numbers you own, and the agreed eligibility flag in your data
- A public HTTPS staging address for callbacks
You own the Twilio account, number, credentials and recipient data. We work on a branch through a company-controlled identity. We never hold your production auth token; a live test uses your staging configuration and your own phone.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “twilio-sms-notifications-with-delivery-receipts” as the subject.