We are pleased to announce that a new Scheduled Timer Event Source is now available for Soracom Flux.

The Scheduled Timer allows you to run your Flux app on a fixed recurring schedule, such as a specific time every day, or a specific day of each week or month.

Together with this release, the existing Timer Event Source, which instead allows you to run your Flux app at regular intervals, will be renamed to Interval Timer to help prevent confusion.

Scheduled Timer is available for the Soracom Flux Standard and Enterprise plans.

For more information, please refer to the following Soracom Flux Event Source documentation:

• Scheduled Timer Event Source
• Interval Timer Event Source

The Soracom Icon Set has been updated.

• The following icons have been removed due to the discontinuation of the Soracom Mosaic service

  • SISS023 (Soracom Mosaic)
  • SIS0209 (S+ Camera B)
  • SIS0225 (S+ Camera Design)

• The following icons have been renamed

  • SIS0208 (S+ Camera A) → Edge AI Camera
  • SIS0214 (S+ Smart Notification Service) → Connector

The updated icon set is available in PowerPoint, PNG, and SVG formats, and can be downloaded from the Soracom Icon Set download page.

We would like to inform customers that we have decided to postpone IPv6 Access Support for the Soracom API, which we previously announced would be released on March 6, 2025, due to issues identified in certain components. This postponement will allow us to prevent unexpected behavior when using the Soracom API with an IPv6 address. We will provide an update once the necessary fixes are completed.

We apologize for any inconvenience this may cause and appreciate your understanding.

We are pleased to announce the following coverage updates for Soracom Air for Cellular connectivity.

plan01s and plan01s-LDV

(*1) plan01s only

planP1

Note: This is an update to the Postponement of Increased HTTP Keep-Alive timeout for Soracom Entry Points announcement made in February.

When a device sends data to Soracom using HTTP, it may optionally specify a Connection: keep-alive directive in the HTTP request header in order to reuse the underlying TCP connection and reduce the reconnection data usage when sending additional HTTP requests.

Until now, the maximum HTTP Keep-Alive timeout supported by Soracom HTTP entry points has been 5 seconds. With this update, the maximum timeout will be increased to 65 seconds for the entry points belows. This change will allow Soracom Air for Cellular and Soracom Arc devices sending HTTP requests to these entry points at intervals shorter than 65 seconds to maintain the connection and reduce data usage.

Affected Entry Points

• Soracom Beam HTTP Entry Point
• Soracom Beam Website Entry Point
• Soracom Funk HTTP Entry Point
• Soracom Funnel HTTP Entry Point
• Soracom Harvest Data/Files HTTP Entry Point
• Unified Endpoint HTTP Entry Point

Effective Date

This update will be rolled out starting from April 7, 2025.

Please note that the effective date may change without prior notice.

Action Required

If your device cannot support the extended Keep-Alive timeout, we recommend disabling Keep-Alive by including the Connection: close directive in your HTTP request headers.

If you have any questions or concerns, please don't hesitate to contact the Soracom Support team.

We are excited to announce two new downlink APIs, Sim:sendDownlinkHttp and Sim:sendDownlinkSsh, which allow you to send data and commands to IoT SIM devices through the Soracom API.

Traditionally, sending cloud-to-device data or commands via IP communication has been difficult due to firewall and routing restrictions that require complicated network configurations or device-side applications.

These new APIs allow you to create HTTP/HTTPS requests or SSH connections directly to your device from within Soracom, and removes the need to set up advanced network architecture, keep track of device IP addresses, or implement custom device-side logic. Simply call the downlink API specifying the data or commands to send, and Soracom will create the request or connection and return any response or output from the device back as the response of the API call.

These APIs are especially beneficial to battery-powered or legacy embedded devices with resource contraints. When combined with Soracom Flux, calling these APIs can even be automated in order to easily build sophisticated IoT systems, such as sending commands to devices based on detected sensor data or cloud events.

Please note: Pricing for Sim:sendDownlinkHttp and Sim:sendDownlinkSsh APIs is scheduled to be announced in June 2025. Until then, these APIs are free to use.

For a detailed usage guide, please see the Remote Command documentation.

We are pleased to introduce Default Variables and improved Query functionality in Soracom Lagoon 3 to reduce manual work when creating dashboards and to visualize and manage data more efficiently.

Default Variables

Default Variables allow a viewer to easily change the devices and data series displayed in the panels of a dashboard, or to automatically repeat displayed panels for multiple devices. When you create a new dashboard, the following Default Variables will now be created automatically:

• resource_types: The resource type to display, such as Air, Sigfox, Inventory Device, etc.
• groups: The Soracom groups to display from the selected resource type (such as data from Air resources in a specific group)
• resources: The specific resources to display from the selected resource type and groups (such as data from a specific IoT SIM)
• properties: The data series to display

For more information, see the Soracom Lagoon: Variables documentation.

Query Editor

The Query editor now provides a Group option that allows you to easily select multiple resources that belong to a particular Soracom group. We have also redesigned the Query editor interface to make each field clearer and less confusing when configuring a query.

For more information, see the Soracom Lagoon: Query documentation.

If you have any questions, please feel free to contact Soracom Support.

Currently, prepaid coupons are available for purchase by both individual and corporate accounts in Japan. These coupons can be used to pay for IoT SIM basic and data usage fees, Soracom Beam service fees, and other platform fees. For more details, please visit Prepaid Coupons (Japanese).

Starting April 1, 2026, prepaid coupons will no longer be available for purchase by customers with individual accounts.

This change will not affect customers with corporate accounts who will continue to be able to purchase prepaid coupons after April 1, 2026.

If you are unsure if your account is registered as an individual or corporate account, or if you have other questions or concerns, please contact Soracom Support.

Soracom is expanding its support for IPv6. As part of this effort, starting March 20, 2025, you will be able to access the Soracom API using IPv6.

• If explicitly specified, you will be able to use the Soracom API with IPv6. If not specified, you can continue using the API with IPv4 as before.
• When accessed via IPv6, audit logs will record the IPv6 address.
• Soracom Napter does not support specifying an IPv6 address in the source IP address range, meaning it cannot be used with IPv6.

Scheduled Change Date

March 20, 2025

If you have any questions, please contact Soracom Support.

Soracom Access Management (SAM) permissions can be configured to allow or deny access based on IP addresses, both in SAM User permission statements and Switch User trust policy statements. IP addresses are specified using the sourceIp variable and the ipAddress function.

With this update, the sourceIp variable and the ipAddress function now support IPv6 addresses. This means that, in addition to IPv4 addresses, you can now also manage access using IPv6 addresses when configuring SAM User permissions and Switch User trust policies.

Important Considerations When Denying Access by IPv4 Address

Please note that if you have configured a rule to deny access based on an IPv4 address such as in the permission statement example below, the deny rule will only be enforced for IPv4 addresses and a user will be able to bypass the rule by accessing using an IPv6 address.

{
  "statements": [
    {
      "effect": "allow",
      "api": [
        "Sim:*",
        "Group:*"
      ]
    },
    {
      "effect": "deny",
      "api": [
        "Sim:*",
        "Group:*"
      ],
      "condition": "ipAddress('xxx.xxx.xxx.xxx/24')"
    }
  ]
}

In general, we do not recommend denying access based on IPv4 or IPv6 addresses, since a user can easily change their IP addresses and bypass restrictions.

Instead, we recommend configuring access to explicitly allow specific IP addresses or IP address ranges that you own or control, as shown in the following example:

{
  "statements": [
    {
      "effect": "allow",
      "api": [
        "Sim:*",
        "Group:*"
      ],
      "condition": "ipAddress('yyy.yyy.yyy.yyy/24')"
    }
  ]
}

If you have any questions, please feel free to contact Soracom Support.