REST API Alarm Sessions: Filtering by "modified" causes 400 Bad Request when new alarm arrives

MIP
1

Hi ,

I am encountering a severe and highly reproducible backend issue when polling for alarms via the REST API (/api/rest/v1/alarmSessions/{id}/alarms).

When registering an alarm session, if I apply a filter using the "time" target, everything works flawlessly. However, if I change the target to "modified", the API abruptly drops the connection with a 400 Bad Request the exact moment a new alarm is triggered or modified.

Steps to Reproduce:

  1. Register the Session: I register an alarm session with the following payload, filtering by modified:

JSON

{
    "filterBy": [
        {
            "operator": "gt", 
            "target": "modified", 
            "value": "2026-03-06T05:50:00.002Z"
        }
    ],
    "orderBy": [
        {
            "target": "modified", 
            "direction": "asc"
        }
    ]
}

  1. Start Polling: I poll the session’s /alarms endpoint every 10 seconds.

  2. Initial Responses (Working): As long as there are no new or modified alarms in the system, the server correctly responds with a 200 OK and the empty structure:

JSON

{"deletedFromSession":[],"addedToSession":[],"updatedInSession":[]}

  1. The Crash: The moment a new alarm arrives in XProtect (or an existing one is modified), the very next polling request instantly fails.

    • Status: 400 Bad Request

    • Body: 0 bytes (Empty)

2

You do not mention the version you are using, please let us know. Is this on XProtect VMS version 2025R3?

3

We are using 2024 R2

4

I reproduced your observations using 2025R3 and have reported it to Milestone Development. I will let you know what they find.

5

That works, thank you.

6

Milestone Development have developed a patch for the 2025R3 Event Server. Please find it here.