Reference · built on requestConnectorSensors, meters & gateways

Sigfox

Devices, device types, uplink messages, locations, and callbacks from the Sigfox 0G network backend operated by UnaBiz.

Request accessPricing ↗

About

Sigfox is a low-power wide-area network run by UnaBiz. Devices send short uplink frames that the Sigfox Cloud stores as messages and forwards to your server through callbacks set on a device type. The backend API at api.sigfox.com/v2 exposes devices, device types, groups, contracts, messages, locations, and the callbacks that failed to deliver. A downlink carries up to 8 bytes and goes out only after a device asks for one.

An operator on Fibric reads the messages and the undelivered callbacks and proposes the downlink, the callback fix, or the device change for your approval.

This is a reference listing. It documents what Fibric would read from Sigfox and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Devices through GET /devices/{id} with state, comState, lqi, lastCom, sequenceNumber, token, and automaticRenewalStatus
  • Messages per device or device type through GET /devices/{id}/messages and GET /device-types/{id}/messages, with time, data, seqNumber, lqi, nbFrames, and rinfos
  • Computed device locations through GET /devices/{id}/locations when the contract carries the Atlas option
  • Undelivered callbacks and errors per device, device type, or group through the callbacks-not-delivered endpoints
  • Callbacks on a device type: channel URL, BATCH_URL, or EMAIL; type DATA, SERVICE, or ERROR; and a dead flag when the last delivery failed
  • UPLINK and DATA_ADVANCED callbacks pushed to your URL with device, time, data, seqNumber, and, by contract option, rssi, station, and geolocation
  • Message counts for the last day, week, and month through GET /devices/{id}/messages/metric, and consumption per device by year and month

Proposed actions

  • Target capability: propose a callback on a device type through POST /device-types/{id}/callbacks with url, httpMethod, headers, and bodyTemplate
  • Target capability: propose enabling or disabling a callback through PUT /device-types/{id}/callbacks/{callbackId}/enable
  • Target capability: propose the downlink answer to a BIDIR callback: downlinkData of 8 bytes in hexadecimal, or noData
  • Target capability: propose a device update through PUT /devices/{id}, or a bulk suspend, resume, or restart through the /devices/bulk endpoints
  • Target capability: propose a device type's downlinkMode, keepAlive, or alertEmail through PUT /device-types/{id}

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Spot the meter that fell silent

    Read lastCom, state, and comState for every device under a group. A DEAD state means the device missed its keepAlive. Propose the site visit or the replacement for approval.

    With Sensor Health, Submeter Drift

  • Repair a broken callback before data is lost

    Poll callbacks-not-delivered per device type and watch the dead flag on each callback. When deliveries fail, propose the URL or header fix and the re-enable, leaving a record of what changed.

    With Integration Health, Webhook Replay

  • Answer a device with a downlink

    When a BIDIR callback arrives with ack true, the answer follows a rule you approved in advance: downlinkData from the latest reading, or noData. Each answer is logged.

    With Cold Room Watch, Leak Response

  • Track an asset by network location

    Read computedLocation on each message or GET /devices/{id}/locations under the Atlas option. When an asset leaves its expected area, propose the notice.

    With Route Deviation, Yard Moves

Requirements

  • A Sigfox backend group with an API user holding at least one profile; read roles read devices and messages, write roles create callbacks
  • Callbacks configured on each device type, with SNI enabled for TLS endpoints and a URL, BATCH_URL, or EMAIL channel
  • A public HTTPS endpoint to receive callbacks; a BIDIR callback expects a JSON answer keyed by device id
  • Contract options NETWORK METADATA and Atlas geolocation if rssi, station, and computedLocation are needed
Authentication
HTTP Basic authentication with an API user's login and password created under API access on a group, or an OAuth 2.0 client credentials token from auth.sigfox.com/oauth2/token using the same credentials.

Limits

  • GET /devices/{id}/messages: 15 parallel requests per second; GET /devices: 50 requests every 10 seconds; PUT or DELETE on a device: 1 request every 60 minutes
  • GET /device-types/{id}/messages and callbacks-not-delivered are limited to 10 requests every 10 seconds; excess returns HTTP 429
  • A downlink payload is 8 bytes and is sent only after a device requests one; the device maker sets the request frequency
  • New SERVICE STATUS callbacks are disabled from September 2026 and the service ends in April 2027; battery and temperature status need another source

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Sigfox ↗

Questions and answers

Does Sigfox push messages or do I poll?
Both are documented. Callbacks on a device type push each uplink to your URL as it arrives, or BATCH_URL groups a device type's messages within a 1 second period. GET /devices/{id}/messages returns history with since and before in milliseconds, at 15 parallel requests per second.
How large is a downlink and when is it sent?
Up to 8 bytes, given as a hexadecimal string. A downlink goes out only after an uplink that carries the downlink request flag. With downlinkMode CALLBACK the BIDIR callback answers with downlinkData keyed by device id, or noData; with DIRECT the device type's downlinkDataString is sent.
Which credentials does the API take?
An API user created under API access on a group, with one or more profiles. Requests use HTTP Basic with its login and password over HTTPS, or an OAuth 2.0 client credentials token from auth.sigfox.com/oauth2/token. CORS and JSONP are unsupported, so browser calls need a reverse proxy.
Ask about Sigfox

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Sigfox through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy