Data Routing Resilience Improvement Scheduled for End of April 2026

Starting from April 21, 2026, the resilience of data routing to your servers will be enhanced across all your Live Objects accounts

In case one or more of your servers become unavailable, messages routed via HTTP push or MQTT application can be queued for a guaranteed duration regardless of the volume of data routed on your account, then automatically sent to your server once it is available again.

What will be the guaranteed queuing duration?

It depends on your plan:

• IoT Connect Low Power – Basic : 24 hours
• IoT Connect Low Power – Premium : 7 days

For other plans, please contact us via the Business Inquiry form.

What does this bring to the current operation?

Currently, if you use HTTP push, the retry policy is limited to a maximum of 24 hours for all plans. Additionally, a significant slowdown in your servers’ response times combined with heavy traffic load can render the current retry mechanism ineffective, leading to message loss. From the end of April, these limitations will be lifted, and depending on your plan, you will benefit from an extended retry policy of up to 7 days.

If you route your data via MQTT (application mode), the queuing duration is currently limited by the memory allocated to your FIFOs on Live Objects. Moreover, it is necessary to delete and recreate a FIFO to adjust the memory size as your traffic grows or to enable/disable queuing. This involves a delicate migration process. These limitations will be removed with the April update: the queuing duration will depend solely on your plan, and enabling/disabling queuing can be done on the fly.

How to benefit from this feature?

This improvement will be deployed on April 21 and will be automatically activated on all your Live Objects accounts.

I want to disable queuing during data routing, how to proceed?

You might prefer not to queue messages in case of server unavailability for various reasons (test traffic, need for “fresh” data, etc.).

If you are using MQTT:

• Before April 21, select “No” for Retention when creating the FIFO. This parameter cannot be changed once the FIFO is created.

• After April 21, simply uncheck the “Keep unconsumed messages” option in the routing rule settings. This parameter can be modified at any time.

This option will be unchecked by default on rules pointing to FIFOs where retention was disabled before April 21.

If you are using HTTP push:

Simply uncheck the “Retry” option in the failure policy of the routing rule settings.

How will FIFO management evolve?

Currently, you need to create a FIFO queue for each MQTT publish topic in your routing rules, allocating a fixed size in bytes and configuring the maximum retention duration (TTL).

After April 21, you will only need to specify the MQTT publish topic when creating the routing rule. The associated FIFO will be automatically created if it doesn’t already exist, without needing to specify size or retention. Similarly, the FIFO will be automatically deleted when the routing rule is removed. On the Live Objects portal, the FIFO list page will be moved next to the routing rules.

What is the impact of the April 21 operation?

During the activation of this feature in production, FIFOs will be automatically converted to the new format without any intervention from you, and without data loss. Some messages may arrive out of order during the transition.

There will be no impact on HTTP push traffic.

Are there any changes planned for the APIs used to manipulate or query FIFOs?

As part of this evolution, here are the upcoming changes:

API	Fonction	from April 21st 2026	from October 30st 2025
POST /api/v0/topics/fifo	Creating a new FIFO	Service will be maintained, but memory size and TTL parameters will be ignored during FIFO creation, as FIFOs will no longer be limited in memory size, and TTL will depend on the noRetention parameter of fifoPublishAction. The API will be deprecated and replaced by POST /api/v1/event2action/actionPolicies	Removed
DELETE /api/v0/topics/fifo/{fifoName}	Deleting a FIFO	Service will be maintained. Response modification: the API will return 200 when the FIFO doen’t exists or has been deleted. This API will be deprecated and replaced by DELETE /api/v1/event2action/actionPolicies	Removed
GET /api/v0/topics/fifo GET/api/v0/topics/fifo/{fifoName}	Listing FIFO topics, Getting a FIFO	Service will be maintained. Response data changes: messageTtl will reflect the queuing duration based on the plan, maxLengthBytes will be -1. The API will be deprecated and replaced by GET /api/v1/event2action/fifos and GET /api/v1/event2action/fifos/{fifoName}. To check the total number of messages waiting on a fifoPublish action, you can also use GET /api/v1/event2action/metrics/actionPolicies/{policyId}/actions/{actionId}. Additionally, if you monitor the number of queued messages programmatically to detect routing incidents, you will be able to receive email notifications in case messages are not delivered for an hour or more, by configuring an alert in this menu : Alarms & reports > Alarms configuration > Message routing.	Removed

Would you like to know more?

Contact us via the Business Inquiry form.