During November 2017 we will be resetting our message IDs. We will be announcing a more specific release date for this change shortly. Customers that use our SOAP or HTTP SMS APIs to poll for inbound messages and check receipt status are potentially at risk of being affected by this change depending on how they are using the current message ID values.
We’re making this change because we’ve sent and received 2 billion messages since Dynmark launched its SMS platform and our database is nearing the limit for a 32 bit integer message ID. Starting again from 0 will have the least impact on customers and integrators.
What this means
The SOAP GetInboundMessagesSinceMessage method and the HTTP GetInboundMessagesSince method may no longer return new inbound messages if your integration assumes that the transactionID parameter is ever increasing. If your integration sets the transactionID parameter to the maximum ID returned from the previous call to GetInboundMessagesSinceMessage then there will be no side effects. However if your integration assumes an incremented value instead of using the greatest returned value then you will need to implement this change as soon as possible.
Other API methods that will return low value message IDs after the change are:
For a standard integration, calls to this group of API methods are very unlikely to be impacted by the change.