The Sigfox APIv2 is out !

In a previous post, I was complaining a bit about the Sigfox API. At this time Sigfox was already working on a new version of the APIs.

Today Sigfox released the API version 2 for managing devices, subscriptions, messages… And this new version based on REST and JSON standards is a really positive rupture compared to the previous one.

More than a new version of the API set it’s also the full deployment of some of the new backend components now accessible by the API deployment. As part of this the 2018 deployed new Group entity, the asynchronous device creation/edition processing and the coming replacement of the callback duplicates to the equivalent with API.

As part of this APIs also some coming features like different level of geolocation precision, payload encryption and many more…

Continue reading

Enhanced Sigfox API services

Since I’m using Sigfox backend there are a lot of operations I’m regularly manually doing. Thanks to the Sigfox API, it is possible to automate these manual operations to gain in productivity and save time.

The most consuming operation were for me to manage the device type because each of them have multiple callback and every callback uses many parameters. The callback replication is for me a recurrent operation when adding a new contract, when creating a new version of application, when instancing for dev, prod… It’s also a complex operation when you have to ask a third party ( like a client ) to configure a device-type for connecting to your service. As a consequence these operations are the first one I’ve automated thanks to the Sigfox Api.

I’ve decided to publish this usefull code to let you saves time on these operation with a new set of API accessible on IngeniousThings Sigfox Api portal and available on GitHub as OpenSource.

In this set of API (actually 3, will grow) you will find operation to export/import a full deviceType configuration and to duplicate a DeviceType.

Have fun !

Offer a better developer experience to Sigfox API

As a backend developer, the Sigfox API is not a really good experience. This for multiple reasons and it is a good example on how a really good product can get a developer push-back just because of the interaction layer.

I can’t change the API itself (and its not y role) but as I was bored to use POSTMAN tool  and the Sigfox backend documentation (who already used it will understand) I decided to spend some hours this week to rewrite most of the API endpoint into a clean open-api format into a Spring application to get benefit of the SpringFox swagger front.

This project is not fully terminated but already in place with the most used API endpoint. The next will arrive soon. Read mode to get access.

Continue reading