How to troubleshoot/verify Sigfox callbacks using curl or postman

When Sigfox Backend shows a failed callback, it can sometimes be hard to troubleshoot why the callback failed. unfortunately, Sigfox Backend does not show the response body, which is often useful in finding out why the request wasn't accepted. Here is an example of a failed callback:

By clicking on the red icon, we can see more information about the callback request:

From this, wee see 401 – Unauthorized, which does say a bit, but not the full story. By copying all details, we can perform the request ourselves using curl:

curl -i -X POST \
> -H "accept-encoding: gzip,deflate" \
> -H "accept-language: fr" \
> -H "myheader: myvalue" \
> -H "accept-charset: UTF-8;q=0.9,*;q=0.7" \
> -H "user-agent: SIGFOX" \
> -H "content-type: application/json" \
> -d '{
>   "device": "21FD11",
>   "seqNumber": 2792,
>   "time": 1593610057,
>   "data": "3020f06322a48d1f0708049c",
>   "lqi": "Good",
>   "linkQuality": 2,
>   "fixedLat": 0.0,
>   "fixedLng": 0.0,
>   "operatorName": "SIGFOX_Sweden_IoTSweden",
>   "countryCode": "752",
>   "deviceTypeId": "5a5df0da9e93a11a72eda3db",
>   "duplicates": [{"bsId":"3E75","rssi":-138.0,"nbRep":2,"snr":7.44},{"bsId":"BF23","rssi":-60.0,"nbRep":3,"snr":30.0}],
>   "computedLocation": {"lat":57.66489888391004,"lng":11.977901749315382,"radius":18400,"source":2,"status":1},
>   "type": 0,
>   "InTrip": true,
>   "FixFailed": true,
>   "Lat": 576974880,
>   "Lon": 119508388,
>   "Heading": 8,
>   "Speed": 4,
>   "Bat": 156
> }'

We get the following response:

HTTP/1.1 401 Unauthorized
Date: Wed, 01 Jul 2020 13:51:33 GMT
Server: Apache
WWW-Authenticate: Basic realm="Authentication required"
Content-Length: 437
Content-Type: text/html; charset=iso-8859-1

<title>401 Unauthorized</title>
<p>This server could not verify that you
are authorized to access the document
requested.  Either you supplied the wrong
credentials (e.g., bad password), or your
browser doesn't understand how to supply
the credentials required.</p>
<address>Apache Server at Port 80</address>

Note that the content-length and host headers will be auto-generated by curl and should therefore be omitted. Also not that Sigfox Backend prints a space before the : (example: accept-language : fr). This space needs to be removed, so the header looks like this: -H "accept-language: fr". We pass the -i parameter to ask curl to display the response headers.

If you prefer a graphical tool, you can use Postman instead of Curl:

From this request we clearly see that we need to supply credentials, which is a common problem. A similar error message can be seen when performing an unauthorized request to Microsoft Azure IoT Hub:

HTTP/1.1 401 Unauthorized
Content-Length: 161
Content-Type: application/json; charset=utf-8
Server: Microsoft-HTTPAPI/2.0
x-ms-request-id: 8d2676e1-202e-4629-8580-ddd2238a1bff
iothub-errorcode: IotHubUnauthorizedAccess
Date: Wed, 01 Jul 2020 13:56:48 GMT

{"Message":"ErrorCode:IotHubUnauthorizedAccess;Unauthorized","ExceptionMessage":"Tracking ID:8d2676e1202e46298580ddd2238a1bff-G:9-TimeStamp:07/01/2020 13:56:49"}

We can now fix the authorization error and try again:

curl -i -X POST -H "accept-encoding: gzip,deflate" -H "accept-language: fr" -H "myheader: myvalue" -H "accept-charset: UTF-8;q=0.9,*;q=0.7" -H "user-agent: SIGFOX" -H "content-type: application/json" -H "Authorization: Basic c2lnZm94OnRlc3Q=" -d '{
  "device": "21FD11",
  "seqNumber": 2792,
  "time": 1593610057,
  "data": "3020f06322a48d1f0708049c",
  "lqi": "Good",
  "linkQuality": 2,
  "fixedLat": 0.0,
  "fixedLng": 0.0,
  "operatorName": "SIGFOX_Sweden_IoTSweden",
  "countryCode": "752",
  "deviceTypeId": "5a5df0da9e93a11a72eda3db",
  "duplicates": [{"bsId":"3E75","rssi":-138.0,"nbRep":2,"snr":7.44},{"bsId":"BF23","rssi":-60.0,"nbRep":3,"snr":30.0}],
  "computedLocation": {"lat":57.66489888391004,"lng":11.977901749315382,"radius":18400,"source":2,"status":1},
  "type": 0,
  "InTrip": true,
  "FixFailed": true,
  "Lat": 576974880,
  "Lon": 119508388,
  "Heading": 8,
  "Speed": 4,
  "Bat": 156
HTTP/1.1 200 OK
Date: Wed, 01 Jul 2020 14:01:39 GMT
Server: Apache
Upgrade: h2,h2c
Connection: Upgrade
X-Powered-By: PHP/7.4.7
Content-Length: 80
Content-Type: text/html; charset=UTF-8


HTTP/1.1 200 OK shows that the request was accepted. If we didnt get things right, we can look at the response and modify the request until we get it right. When everything is OK, we can update the callback configuration on Sigfox Backend, and verify that everything works:

Leave a Reply

Your email address will not be published. Required fields are marked *