Sends a behavior to a device.
Behaviors might not reach the device instantly based on the priority.

• Low priority behaviors are placed in a queue, and handled to the device whenever the device communicates with the platform. Devices communicate with the platform based on their fixed reporting schedule, or whenever a specific event is triggered.
• For high priority behaviors, the platform will make its best effort to deliver the behavior as soon as possible.

The following behavior defines how to update the reporting frequency of a device

{
  "name": "REPORT_FREQ",
  "description": "Change Reporting Frequency",
  "parameters": [
    {
      "name": "frequency",
      "type": "number",
      "min": 5,
      "max": 60
    }
  ]
}

To send this behavior to a device, the following POST body should be sent:

{
  "name": "REPORT_FREQ",
  "parameters": {
      "frequency": 45
    },
  "highPriority": false
}

Starter interrupt

On supported devices (currently the GV57MG), the INTERRUPT behavior remotely enables or disables the starter interrupt, allowing the vehicle to be immobilized or released.

Parameters:

• interrupt — enabled or disabled. Engages the starter interrupt (immobilizes the vehicle) or releases it.

To engage the starter interrupt (immobilize the vehicle), send:

{
  "name": "INTERRUPT",
  "parameters": {
      "interrupt": "enabled"
    },
  "highPriority": true
}

Send "interrupt": "disabled" to release it. For operator safety, the device will not engage the starter interrupt while the ignition is on.

Physical immobilization depends on correct starter-interrupt hardware installation; the API confirms command delivery and the device's reported output state, not the physical outcome.

To read the current starter interrupt state, use GET /behaviors/{imei}/history and take the most recent confirmed INTERRUPT entry — its parameterValues array contains the interrupt entry with the last applied value (enabled or disabled). This is the same last-commanded value shown in the Hapn dashboard.

Starter interrupt schedule

The INTERRUPT_SCHEDULE behavior configures a recurring weekly schedule for the starter interrupt on supported devices (currently the GV57MG), with independent time windows per weekday.

The windows define when the equipment is available for use: the starter interrupt is disabled during these time frames and engaged outside them (the vehicle can start within the windows and is immobilized outside them).

Parameters:

• interrupt — enabled or disabled. Turns the schedule on or off.
• day_of_work — a 2-character hex bitmask of the active weekdays, where bit 0 = Monday … bit 6 = Sunday. Example: Monday–Friday = 1f, the whole week = 7f. Required when interrupt is enabled (omitting it returns a 400); not needed when disabling.
• {weekday}_start_time / {weekday}_end_time — the window for each weekday in 24-hour HHMM format (e.g. 0800). The end time must be later than the start time (a window cannot cross midnight). Weekday names are lowercase: monday…sunday.

Example — make the equipment available for use Monday through Friday, 08:00–17:00, and immobilized outside those windows:

{
  "name": "INTERRUPT_SCHEDULE",
  "parameters": {
      "interrupt": "enabled",
      "day_of_work": "1f",
      "monday_start_time": "0800",
      "monday_end_time": "1700",
      "tuesday_start_time": "0800",
      "tuesday_end_time": "1700",
      "wednesday_start_time": "0800",
      "wednesday_end_time": "1700",
      "thursday_start_time": "0800",
      "thursday_end_time": "1700",
      "friday_start_time": "0800",
      "friday_end_time": "1700"
    },
  "highPriority": true
}

Send "interrupt": "disabled" to turn the schedule off. As with the on-demand interrupt, the device will not engage the starter interrupt while the ignition is on.

To read the current schedule, use GET /behaviors/{imei}/history and take the most recent confirmed INTERRUPT_SCHEDULE entry — its parameterValues array holds the last applied configuration (interrupt, day_of_work, and the per-weekday start/end times). As with the on-demand interrupt, this is the last-commanded value.

Sending a behavior to a device returns a task identifier that can later be used to query the status of a behavior.