Action policy

The relationship between a trigger and multiple actions is called an action policy. The action policy must be provisioned in Live Objects with the HTTP API or using the web portal. Once the action policy is provisioned and enabled (field enabled set to true), your messages will be routed using the chosen action mode (FIFO queue or HTTP push).

Prior to provisioning your rule with an http push action, please make sure your web server is up-and-running.

  • you have created your FIFO in Live Objects if you want to use a FIFO queue

  • your web server is up and running if you want to use an HTTP push action

Only new routed messages/events are delivered once the action policy is provisioned. Existing data messages already stored in Live Objects are not re-routed.

An action policy is composed of 2 main sections:

  • triggers: define what you want to route. Usually, one trigger is defined in one action policy, except for device provisioning events, where you can define a trigger for deviceCreated events, and a trigger for deviceDeleted events, in the same action policy.

  • actions: define how you want to route these messages/events.

The action policy API is detailed in Swagger.

Provisioning

To create a new action policy:

Endpoint:

POST /api/v1/event2action/actionPolicies
An action policy for message routing has the following top level data representation:
{
  "name": "some_user_defined_policy_name",
  "enabled": true,
  "triggers": {
    "dataMessage": {
      "version": 1,
      "filter": {
        "connectors": [
          "lora"
        ],
        "groupPaths": [
          {
            "includeSubPath": false,
            "path": "/europe/france"
          }
        ],
        "tags": [
          ["HIGH","ALERT"],
          ["PROD"]
        ]
      }
    }
  },
  "actions": {
    "fifoPublish": [
      {
        "fifoName": "myFifo"
      }
    ]
  }
}

The policy id is automatically created by Live Objects and will be returned in the POST response body.
field name is required description

name

optional

Defines a user-friendly name for the action policy

enabled

required

Enable or disable the action policy

suspension

optional

In case of abnormal activity on this rule, it can be suspended (enabled will be set to false). Read-only: this field is handled by the platform. Once the problem is corrected, use the PUT API with enabled=true to resume the rule.

triggers

required

Defines the type of trigger that will start an action.

Filtering section: criteria in a filter are combined with an AND boolean logic. The OR operator is applied between the items inside each filter list. The filters depend on the trigger type.

Note: the triggers object should have exactly one trigger defined in most cases (except for deviceCreated & deviceDeleted).

dataMessage

optional

 
Available filters for data message:

  • connectors: a list of interfaces to be monitored ("http", "mqtt", "lora", "sms", "x-connector")

  • deviceIds: a list of device identifiers (as String)

  • groupPaths: a list of device group paths

  • tags: a list of lists of tags.

deviceStatus

optional

The device status can be one of the following: "ONLINE", "OFFLINE", "REGISTERED", "DELETED", "ACTIVATED"…​ See all the device status in this chapter.

Available filters for the device status events:

  • connectors: a list of interfaces to be monitored ("http", "mqtt", "lora", "sms", "x-connector")

  • groupPaths: a list of device group paths

deviceCreated

optional

 
Available filters for the device created events:

  • connectors: a list of interfaces to be monitored ("http", "mqtt", "lora", "sms", "x-connector")

  • groupPaths: a list of device group paths

  • tags: a list of lists of tags

deviceDeleted

optional

 
Available filters for the device deleted events:

  • connectors: a list of interfaces to be monitored ("http", "mqtt", "lora", "sms", "x-connector")

  • groupPaths: a list of device group paths

  • tags: a list of lists of tags

commandStatus

optional

 
Available filters for the command status events:

  • status: a list of command status to be monitored ("pending", "processed"…​) See more details in the device management chapter.

loraNetwork

optional

 
Available filter for the network info events from LoRa® devices:

  • messageTypes: a list of LoRa® network info events within six available message types:

    • "UNCONFIRMED_DATA_UP"

    • "CONFIRMED_DATA_UP"

    • "UNCONFIRMED_DATA_DOWN"

    • "CONFIRMED_DATA_DOWN"

    • "JOIN_REQUEST"

    • "JOIN_ACCEPT"

loraGatewayStatus

optional

Sent event when a LoRa® gateway status changes. Status can be "ONLINE", "OFFLINE" or "UNKNOWN".

connectivityManagementPlatformEvent

optional

Event sent by your cellular connectivity management platform (e.g. Orange CMP 'Portail M2M' / 'Conecta IoT' / 'Simply IoT' platform).

alarmEvent

optional

Available filter for alarm events: alarmRule.type with supported values messageDeliverySuccessRatio (event sent when a message delivery success ratio alarm is triggered for account metrics monitoring) and actionSuspended (event sent when an action is suspended due to high error rate). Supported alarms full description is available in account alarming chapter.

actions

required

Defines the type of action:

emails

optional

A collection of Email actions (see Email notification section)

sms

optional

A collection of SMS actions (see SMS notification section)

fifoPublish

optional

A collection of FIFO names where the event message will be published (see FIFO notification section)

httpPush

optional

A collection of HTTP push actions (see HTTP push action section)

azureEventHubs

optional

A collection of Azure Event Hubs actions (see Azure Event Hubs notification section)

To retrieve your action policy:

Endpoint:

GET /api/v1/event2action/actionPolicies/{policyId}

Examples

An example of an action policy with triggering on a new data message for a specific device. The output message is routed to a specific FIFO.
{
    "id": "202ada2a-e267-4427-9d7f-2756c2a2b1dd",
    "name": "push data fifo",
    "enabled": true,
    "triggers": {
        "dataMessage": {
            "version": 1,
            "filter": {
                "deviceIds": ["<your_device_id>"]
            }
        }
    },
    "actions": {
        "emails": [],
        "sms": [],
        "httpPush": [],
        "fifoPublish": [
            {"fifoName": "<your fifo name>"}
        ]
    }
}
The same example of an action policy with triggering on a new data message for a specific device. the output message is pushed to a website using HTTP Push action.
{
    "id": "202ada2a-e267-4427-9d7f-2756c2a2b1de",
    "name": "Push data message with a webhook",
    "enabled": true,
    "triggers": {
        "dataMessage": {
            "version": 1,
            "filter": {
                "deviceIds": ["<your_device_id>"]
            }
        }
    },
    "actions": {
    "emails": [],
    "sms": [],
    "httpPush": [
    {
        "webhookUrl": "https://webhook.site/....",
        "headers": {
          "authorization": [
            "Bearer 00000000-0000-0000-0000-000000000000"
          ]
        },
        "content": "<text>+<mustache template>",
        "retryOnFailure": true
      }
    ],
    "fifoPublish": []
  }
}

Now that you know how to create an action policy, you can find the format of all public data messages and events in this chapter.
Version 2026.7.0 • Updated date 2026-08-11 12:37:29 UTC