Helpful

CallbacksPrinciples

Callback integration

IP White listing

In order to ensure that you receive callback data, you should whitelist the following IP address range used by the Sigfox cloud. Please refer to Classless Inter-Domain Routing (CIDR) notation for more details.

The currently used IP range is 185.110.96.0/22 
(thus any IP from 185.110.96.1 to 185.110.99.254)

This range may evolve in the future, we will disclose any coming change in Sigfox Backend release notes, and will keep this page up-to-date.

Acknowledgement and retry policy

Upon receiving a callback, the client system must answer and return the appropriate HTTP status code within 10 seconds after receiving the request.

Because of the 10 seconds limit, it is recommended the client system manages received data asynchronously. 

If the client system fails to answer the callback during this time, the following retry policy is applied:

  • The 1st retry is sent 1min after the timeout occurs or an error code is received
  • The 2nd retry is sent 2min after the timeout occurs or an error code is received
  • The 3rd retry is sent 4min after the timeout occurs or an error code is received

If the client system replies too late and the 10 second timeout has occurred, the retry policy will be applied.

It is thus recommended to consider applying deduplication, even in regular cases when the deduplication is done at source because of such possible side effect.

Certificate Authority

General principles and explanation regarding certificate authority.

Difficulty to receive callbacks from the Sigfox Cloud

Sigfox does not trust certificates that are self-signed, i.e. not issued by a Certificate Authority (CA). Therefore, the Sigfox Cloud will not be able to transfer a callback to a server presenting a self-signed certificate.

 

What is a Certificate Authority?

A Certificate Authority (CA) is an entity that issues digital certificates.

The digital certificate warrant the ownership of a public key by the named subject of the certificate.

This allows others (relying parties) to rely upon signatures or assertions made by the private key that corresponds to the public key that is certified.

In this model of trust relationship, a CA is a third party that is trusted by both the subject (owner) of the certificate and the party relying upon the certificate.

In the context of a website, when we use the term digital certificate we often refer to SSL certificates. The CA is the authority responsible for issuing SSL certificates publicly trusted by web browsers.

The CA has the responsibility to validate the entity behind an SSL certificate request and, upon successful validation, the ability to issue publicly trusted SSL certificates that will be accepted by web browsers.

Can't find what you're looking for ?

Have questions? Our worldwide Community of expert fans can answer them.
Have answers? Join the Community and help!

slack logo

Ask the community >