How can I investigate my Bandwidth messages using Search & Logs?Follow
Bandwidth has released a few new tools to assist you with investigating the delivery and performance of your Bandwidth messages. Use these tools as a first step to determining what may be leading to the unexpected behavior you are seeing.
These tools were built to help customers with the following:
- Troubleshoot Messaging Delivery - you can search for messages & identify the current status of the message in real time.
- Monitoring performance & testing - you can monitor the progression of the message to identify any issues during testing and integration.
Troubleshooting with Logs or Search
Message Logs as well as the Search API will allow you to search messages for their status in real time. This enables you to see where your messages are as Bandwidth processes them to send.
Investigating an Outbound Message
First, the request to send a message:
When sending a message using the APIs, you will receive immediate feedback whether the message creation request was successful or not. In the case of a successful request to create a new message, Bandwidth responds with a HTTP 202 - Accepted. When the message creation request fails, you will receive an HTTP error, 4XX, that indicates why the request failed - these messages will not be sent.
After the initial 202 - Accepted response, many customers are waiting for Bandwidth to indicate whether the message was successfully delivered. Callback events and message detail records are not sent or generated until the requested delivery receipt is received or the system times out waiting for the requested delivery receipt from the carrier.
Understanding where your messages are
As Bandwidth processes your request to send a message the message will move through several statuses. This frequently will happen within seconds so you may not see all statuses listed below.
For those usual times when a message is stopped while processing, this tool can help you identify the current status of the message. For example, your message may have been queued as it was processed. This can happen for a number of reasons. You do not need to resend the messages as the queue will empty and your message will continue to process to be sent.
If a customer reaches out to let you know they are not receiving messages, you can go here in real time to understand the status of that message.
Receiving an Inbound Message:
When Bandwidth receives a message destined for a BW number on your account, it passes through a few layers of validation to confirm formatting and filter any unwanted messages.
We will attempt to send this to you until your server responds with a 2xx. We will rety for 24 hours (For those using SMPP, we retry for an hour) . If your server rejects the message or does not respond with a 2xx within the allotted time, we will fail the message.
For messages that are not accepted by the customer or blocked before attempting to send to you, an error message will indicate to you why the message was not delivered.
Monitoring & Testing using Logs or Search
As you are testing your messaging services initially or as you are monitoring your messages during a certain campaign, you can leverage the real time tools to ensure your messages are being delivered as expected.
Messaging Outbound & Inbound webhooks (callbacks) events compared to Message Logs
Outbound and Inbound Message Webhooks or Callback events are only triggered for final message delivery states when Bandwidth receives a DLR from the Carrier. Message Logs and our get/message api (Message Search) enable you to see all message and delivery statuses as the message is sent or received by Bandwidth.
What if I’m not able to find a message I sent in Search or Logs?
This most frequently happens when there is an issue with the phone number you are sending with. Please confirm the number you are sending from belongs to your account and you are authorized as a user to send from that number. Additionally, if the request to send a message fails and a HTTP status code is provided you will not see these messages as those failed to create a message to send.
Was this article helpful?
0 out of 0 found this helpful