Incoming Status Reports
Note
Status report webhooks are available in XML format and JSON format.
Once you have sent out messages via our Business Messaging API, you might want to receive status updates in return. These status updates can inform you about: how successful a campaign has been, who has received your message, or in case of failure, when a fallback has been applied. You can view the status updates on the CM-platform's messaging log or receive those statuses in your own system via a webhook.
- API/Webhook - data in your own systems, development required, where also you need to adhere to GDPR.
- Messaging log – data in CM's own platform, accessible for you 24/7, no development required, GDPR compliant.
There are no additional cost to use either one.
The Messaging platform has the option to communicate with a web server whenever a message updates its status. The status reports will be communicated using an HTTP POST request.
Note
Status reports sent towards an API/Webhook will be considered as not delivered when a non-successful response code is returned. Our services will temporarily hold the information and retry the delivery periodically for a maximum of 7 days. Status information will remain available through the Messaging Log.
Configure status reports
You can configure your status report webhook for SMS in the 'Channels'-app.
Please refer to the gateway section to configure your status reports.
You can choose to receive the status report in JSON format:
{
"messages": {
"msg": {
"received": "[CREATED_S]",
"to": "[GSM]",
"reference": "[REFERENCE]",
"status": {
"code": "[STATUS]",
"errorCode": "[STATUSDESCRIPTION]",
"errorDescription": "[STANDARDERRORTEXT]"
},
"operator": "[OPERATOR]"
}
}
}
Or in XML format:
<MESSAGES>
<MSG RECEIVED="[CREATED_S]">
<TO>[GSM]</TO>
<REFERENCE>[REFERENCE]</REFERENCE>
<STATUS>
<CODE>[STATUS]</CODE>
<ERRORCODE>[STATUSDESCRIPTION]</ERRORCODE>
<ERRORDESCRIPTION>[STANDARDERRORTEXT]</ERRORDESCRIPTION>
</STATUS>
</MSG>
</MESSAGES>
Parameter specification
Name | Format | Description |
---|---|---|
Created | Datetime | The moment when the status report was registered on CM.com's platform |
Send | Datetime | The moment when the status report was sent to customer's/your endpoint |
To | String | The recipient of the message, such as the telephone number of the message recipient or another identifier |
Status | Integer | The code describing the current state of the message. 0 = accepted by the operator 1 = rejected by CM or operator 2 = delivered 3 = failed (message was not and will not be delivered) 4 = Read (Not for SMS, only other channels) |
Standard Error | String | The description of the error if the message is in an error-state |
Status Description | String | The description of the current state of the message |
Channel | String | The used communication method via which the status report was received – ie. sms, whatsapp, viber. |
Operator | String | The Mobile Operator of the recipient - if relevant |
Reference | String | The message reference which can be provided by the customer in the outbound message (see business messaging API) |
CustomGrouping CustomGrouping2 CustomGrouping3 | String | The custom groupings set for this Outbound Message (MT) (see business messaging API) |
Note:
- Date/time values are formatted as "yyyy-mm-ddThh:ii:ss" and provided in CEST.
- Status implies the last known status of the message. You can expect multiple status updates, but you are not guaranteed to receive an update for each and every status change. For instance, receiving a status
read
implies it was delivered, even if you never received a report with statusdelivered
. Similarly in some rare cases a status can become failed even after having received a previous status delivered. The reason for this is optimization by the various channel providers.
Updated 12 months ago