Unexpected JSON received by SMS delivery report hook and no client_reference when send had one.

[SARoadrunners]

New JSON format received by delivery report hook and didnt have client_reference which my code depended on.  Client reference was sent.  JSON format didnt match docs so broke my code.  How many more variations are there?

{"at":"2024-04-28T22:56:13.840Z","batch_id":"01HWKERMJ8MZKH0YYJPZ6A5ZNZ","client_reference":"true","code":0,"operator_status_at":"2024-04-28T22:56:00Z","recipient":"12103173758","status":"Delivered","type":"recipient_delivery_report_sms"}

Previously, even if batch had only 1 number in it, the delivery hook JSON would contain a statuses array which contained a recipients array containing just one number as currently documented.

FWIW I'm using PHP.

so...

1. Are there any other JSON variations I should code for?

2. Why was client_reference set to true?  A 32 char hex string was set as client_reference when the SMS was sent.  I'll need to restructure my code if client_reference isn't going to work any more.

[Alexander_Mair]

Hi Jim, thanks for your patience. We are currently reviewing your query with the engineering team. We can assure you that there have been no updates to the JSON format returned by the API. As a general policy, Sinch will not change the JSON format as it breaks backwards compatibility.

[Alexander_Mair]

Hi Jim, we have discussed your problem with the team and we would recommend you double check the value of client_reference in your request. This is because the value of client_reference in the response corresponds to the value in the payload. For more information have a look at Inbound Messages and Delivery Report webhooks.  Hope this helps.

[SARoadrunners]

The main part of my question was that the JSON format and content of the delivery report webhook for "recipient_delivery_report_sms" suddenly didnt match the documents.    What JSON format should I expect going forward for the delivery report webhook - the format I received recently and posted above -or- the one documented that contains a statuses array???

I have already refactored my code to validate the client_reference field to be sure it's what I expect and not to rely on it so that is not an issue for me.  The JSON to expect in the delivery report hook is an issue.

[Alexander_Mair · Accepted solution]

Hi Jim, the sample you got matches the documentation for recipient delivery report https://developers.sinch.com/docs/sms/api-reference/sms/tag/Webhooks/#tag/Webhooks/operation/deliver.... This is the format expected when `type` is set to `recipient_delivery_report_sms`.  As a rule, when type is set to delivery_report_sms you will get the JSON with the statuses array.  We would recommend for you or your team to double check the value of the delivery_report parameter. It will be a recipient delivery report when it is set to per_recipient or per_recipient_final. Apologies for any confusion caused.

[SARoadrunners]

That helps alot!  I am using per_recipient_final in my send request.   When I moved my code from a simple stand alone app into my much larger production code, I must have inadvertently change the delivery_report.  My mistake.  Thanks for your help.  

[SARoadrunners]

FWIW I also now have the client_reference working.  In the process of integrating code our Database admin changed the data type of the value I was putting into the client_reference from string to binary.  The binary value evaluated to 1 or true.  Once I adapted to the data change, your handing of client_reference worked as expected.  My team's mistake again.