Skip to main content
Technical Preview

Overview

Soracom is an IoT connectivity platform: IoT SIMs for cellular devices (Air), data forwarding to clouds and servers (Beam, Funnel, Funk, Unified Endpoint), data and file storage (Harvest Data, Harvest Files), event handlers and LwM2M device management (Inventory). These connectors connect the Coreflux broker to the Soracom API, so plant logic on MQTT can watch and control the SIMs of field gateways and machines, read their data usage and stored data, reconfigure forwarding, and reach devices behind the cellular network with downlink HTTP, ping and SMS.
  • SoracomApi (SoracomRestApi.lot) is a client connector on https://g.api.soracom.io (global coverage) with 44 events from the Soracom API reference.
  • SoracomWebhookReceiver (cloud-iot_soracom_webhook.lot, opt-in, server mode) receives device data that Soracom Beam forwards over HTTP and event handler web requests, so device data and SIM events reach MQTT without polling.
Every endpoint below matches Soracom’s published OpenAPI definition, and every event was checked against the live API (see Status).
For Japan coverage SIMs, change BASE_ADDRESS to https://api.soracom.io. The endpoints are the same, but each coverage holds its own SIMs.

Authentication

An AuthKey grants API access as its user. Create the AuthKey on a SAM user whose permissions cover only the events you use. Keep it in Hub secrets, map it in with GET SECRET, and never publish it, the API key or the token on a topic other clients can read.
Soracom uses a two-step session:
  1. Publish {"body": {"authKeyId": "...", "authKey": "...", "tokenTimeoutSeconds": 3600}} on cloud-iot/soracom/token/create (Auth, POST /v1/auth). The response on cloud-iot/soracom/token/create/response carries apiKey, token and operatorId.
  2. Every other event takes "api_key" and "token" in its MQTT payload and sends them as X-Soracom-API-Key and X-Soracom-Token.
Tokens expire after tokenTimeoutSeconds (180 to 172800 seconds, default 86400), so call Auth again before then. Auth also accepts a SAM user (operatorId, userName, password) or the root account (email, password), but AuthKeys are the right choice for a broker. Suggested secrets: SORACOM_AUTH_KEY_ID and SORACOM_AUTH_KEY. A wrong or expired API key or token returns 403 with {"code":"AGW0011","message":"Invalid API Key or Token"}. A wrong AuthKey on Auth returns 401 with {"code":"AUM0029","message":"Invalid AuthKey supplied."}.

Payload conventions

  • Ids. "sim_id" is the SIM ID (simId in ListSims and GetSim), "imsi" a subscriber IMSI, "group_id" and "handler_id" UUIDs, "device_id" a Soracom Inventory device id. LwM2M events take "object_id", "instance_id" and "lwm2m_resource_id" (for example 3303, 0, 5700).
  • Query strings. Events with ?{query} take a pre-encoded query string. Send "" for none. Usage reports require from, to (Unix seconds) and period (month, day or minutes). Harvest Data, session and status history take from and to in milliseconds.
  • Bodies. Write events and downlinks send "body" unchanged.
  • Paging. List events return up to limit items. Soracom returns the next-page key in the x-soracom-next-key response header, to pass back as last_evaluated_key. The connector publishes the response body, so prefer a large limit or narrower filters (SearchSims, ListSimsInGroup) when the header is not available.

Authentication

Auth (cloud-iot/soracom/token/create)

IoT SIMs

SearchSims (cloud-iot/soracom/sim/search)
UpdateSimSpeedClass (cloud-iot/soracom/sim-speed-class/update)
PutSimTags (cloud-iot/soracom/sim-tags/update)

Usage reports

GetSimAirStats (cloud-iot/soracom/sim-usage/get)

Groups (Air, Beam, Funnel, Funk, Harvest settings)

CreateGroup (cloud-iot/soracom/group/create)
PutGroupConfiguration (cloud-iot/soracom/group-config/update)

Harvest Data

GetSimData (cloud-iot/soracom/harvest-sim-data/get)

Harvest Files

PutFile (cloud-iot/soracom/harvest-file/upload)
SendDownlinkHttp (cloud-iot/soracom/downlink-http/send)
SendSmsToSim (cloud-iot/soracom/sms/send)

Event handlers

CreateEventHandler (cloud-iot/soracom/event-handler/create)

Soracom Inventory (LwM2M devices)

ReadDeviceResource (cloud-iot/soracom/inventory-resource/get)
WriteDeviceResource (cloud-iot/soracom/inventory-resource/update)

Audit logs

Webhook receiver

SoracomWebhookReceiver listens on port 9007 and publishes each delivery on MQTT unchanged:
  1. Beam. Configure the group with PutGroupConfiguration (namespace SoracomBeam) or in the User Console. Use key http://beam.soracom.io:8888/ with destination https://<public host>/soracom/webhook/beam, or key udp://beam.soracom.io:23080 (or tcp://beam.soracom.io:23080) with destination https://<public host>/soracom/webhook/beam-udp. Turn on the IMSI and SIM ID headers and the signature header with a pre-shared key. Devices then send to http://uni.soracom.io (Unified Endpoint) or the Beam entry point. Only POST is received.
  2. Event handlers. Add an ExecuteWebRequestAction (see CreateEventHandler) with url https://<public host>/soracom/webhook/event-handler, httpMethod POST, contentType application/json, a shared-secret header and a body template such as {"simId":"${simId}","imsi":"${imsi}","newStatus":"${newStatus}"}.
  3. Soracom calls the URL from its cloud. Put a reverse proxy or tunnel with a public TLS certificate in front of port 9007, have it check X-Soracom-Signature or the shared-secret header, and forward to http://<broker>:9007/soracom/webhook/.... The connector itself does not check headers, and headers are not forwarded to MQTT.
Deploying the receiver opens an HTTP port on the broker. Deploy it only where you need push delivery.
Soracom Beam also has an MQTT entry point that can forward device MQTT messages straight to a Coreflux broker. That path needs an MQTT bridge, not this REST connector.

Examples

Read one day of data usage for a SIM:
Throttle a SIM that is using too much data:
Helper actions (refresh the session every 12 hours, keep the key and token in the broker with KEEP TOPIC, which is never published to MQTT, poll a SIM, send a set point to a device over HTTP downlink, fan event handler calls out to plant topics):
The helper actions keep the API key and token on retained internal/soracom/... topics. Restrict those topics with broker ACLs so only the broker’s own actions can read them.

Writes

Write events: ActivateSim, DeactivateSim, SuspendSim, SetSimToStandby, UpdateSimSpeedClass, PutSimTags, SetSimGroup, UnsetSimGroup, CreateGroup, PutGroupConfiguration, PutGroupTags, PutFile, SendDownlinkHttp, SendSmsToSim, CreateEventHandler, UpdateEventHandler, WriteDeviceResource, ExecuteDeviceResource. Activating a SIM starts billing, and status, speed class and group changes take effect on the live connection. SendDownlinkHttp and ExecuteDeviceResource act on the device itself, and SendSmsToSim is charged per message. SendDownlinkPing is read-only. No preset deletes anything or terminates a SIM.

Not packaged

Every delete (SIMs, groups, tags, configuration, files, event handlers, devices), SIM termination and registration, virtual SIM creation, Arc, Napter, Krypton, SoraCam, Lagoon, Query Intelligence, billing and payment, users, roles and credential sets, Sigfox and LoRaWAN device APIs, and the Japan host (change BASE_ADDRESS). Harvest Data is written by devices through Unified Endpoint, not through the API.

Status

Technical preview, blocked on the authenticated live test. Every event reaches g.api.soracom.io, and an invalid credential is rejected on all 44 events (403 AGW0011, or 401 AUM0029 on Auth). A SAM user AuthKey and a test SIM are still needed for the read and write round trip.
Last modified on October 21, 2026