We are excited to announce a number of improvements in Messaging Error Visibility which will empower you to better understand your Twilio integration. These changes are being rolled out during 2024.
Visibility on Message Creation API Errors
How things worked historically
When you make a POST to the Programmable Messaging API to create a new message, the Twilio API typically responds with 201 Created and returns a Twilio Message SID for the message so you can track it further. Those messages are visible in the SMS logs and Messaging Insights in the Twilio Console as well as when you list messages via the Programmable Messaging API.
However, when POSTs to create messages encounter an error, Twilio’s API returns a HTTP status code 400 and includes a specific 5-digit Twilio error code to help you understand what went wrong with the request. The messages that returned a 400 response have not historically been visible in the console nor when you make a list request to the API.
Changes we made in 2024:
We want to give you access to all of Twilio’s great tooling to help you understand all of your messages. This improved visibility rolled out on an account by account basis in two phases:
Phase One - We began recording HTTP 400 Errorful message creation attempts
We now record all message creation attempts on your account, including both successful POSTs (201 response) and failed POSTs (400 response). This means that the errorful message creation attempts (400 responses) will become visible to you in your Messaging Logs and Insights as well as when you list messages on the API.
This empowers you to better troubleshoot errors that you may not be tracking well today.
We started deploying this new functionality gradually to Twilio accounts beginning April 3rd, 2024.
Phase Two - We started showing these synchronous message creation errors in the console Error Log experience
You are able to set alerts and receive alerts on all error events related to your attempts to create messages via the Error Log in the Twilio Console.
Things that didn’t change
To minimize disruption and ensure that you don’t need to make code changes in your Twilio integration these important things will stay the same:
- The error response from the Twilio API will stay the same; the status code will still be 400 and the body of the response will remain unchanged. Unfortunately, this means that you still won’t receive the Message SID with these error responses; but they will be available when listing messages via the API.
- We won’t be sending new status updates for synchronous API failures to your webhook receiving infrastructure. As always, the initial status of the message is returned in the synchronous response to your POST, only subsequent updates to a messages status result in status callbacks and EventStream events.
Additional Logging Improvements in 2024
Coverage in Error Log and Alerts - Spring/Summer 2024
We’re increasing error coverage in the console Error Log tooling to ensure that it captures all message errors. We have identified specific error scenarios that result in failed or undelivered messages, and even though status callback webhooks were sent, they were not previously included in the Error Log and Alerting tooling. We will be improving the system by including these errors so you have full visibility on them and can set Error Alarms for console, email, and/or webhook notifications.
Inbound message visibility - Spring 2024
Twilio does not generally allow receiving inbound One Time Passcode (OTP) messages on Twilio numbers. This prevents abuse of Twilio numbers. Previously, these inbound messages were filtered before being processed onto your Twilio account. In order to provide better visibility for all inbound traffic, Twilio will allow you to see these messages, but will be redacting the passcode itself and setting a failed status with error code 30038.
Delivery Errors from Carrier Delivery Receipts - Fall 2024
For a subset of older Twilio accounts, if a message could not be delivered and a reason was returned to us via a delivery receipt from our carriers, this error event would not show up in Error Logs nor trigger Alarms, even though it would show up in Messaging Logs. During September and October, 2024, we will be enabling this behaviour across all accounts in batches with the aim to have all accounts enabled by October 22nd.
Generally these errors are in the range of 300XX with the most common errors being 30008, 30005 and 30003.
If you have Error Alarms set and don’t want to receive alerts for these kinds of errors or you want to change the thresholds of your current alarms, you can edit, delete or set alarms by following the instructions here.