There are a few concepts that are important to understand how Bandwidth's new messaging API functions:
Messaging 2.0 does not keep any records to fetch later. If you need to keep track of delivered, error-ed, received messages after you receive the corresponding callback event, you MUST store the events in the data-store of your choice.
Once we have successfully delivered the callback event and receive an HTTP 2xx response, Bandwidth can no longer provide any detail about that message.
As the messaging 2.0 API does not offer message storage or detailed messaging records, Bandwidth will attempt to deliver every callback until your server replies with a HTTP 2xx status code. If the callback request times out, or your server returns a code less than HTTP 2xx or greater than HTTP 3xx Bandwidth will try to deliver the callback multiple times over the next 24 hours.
After 24 hours, if your server has not returned a HTTP 2xx code, Bandwidth will no longer try to send the callback.
The messaging 2.0 API works off of an internal queuing system. As such, when you POST to the v2/.../messages to create a new message, Bandwidth will reply with an HTTP 202 - Accepted. This indicates that the message has been placed on the queue
As the message progresses through the internal system you will receive a Message Sent callback when the message has been dequeued and on the way to the downstream carrier. You will then receive a Message Delivered callback when the message has been handed off to the downstream carrier.
If at any-point through the process the message fails, you will receive a detailed Message Failed callback with an error code describing the reason for failure.