Hikvision ISAPI AcsEventCond – Missing Records / Serial Gaps Issue (Pagination + SerialNo logic)

[mhamed1]

I'm working with Hikvision Access Control devices using the ISAPI endpoint:
/AccessControl/AcsEvent?format=json
and querying events using AcsEventCond.

Problem​

I'm experiencing missing records when retrieving logs. Specifically:

• Some serialNo values are skipped (gaps in sequence)
• These skipped records are being logged in my system as "missing"
• However, I’m not sure if:
  • The device actually lost those records
  • OR the API is not returning them due to how I'm querying

My Setup​

• Using PHP (cURL) with Digest Auth
• Querying with:
  • searchID
  • searchResultPosition
  • maxResults = 30
  • major = 0 (MAJOR_ALL)
• Then filtering in code for:
  • major == 5 (MAJOR_EVENT)
  • specific minor values (valid access events)

Retrieval Logic​

I have two modes:

1. First run → Time-based​

{
  "startTime": "...",
  "endTime": "..."
}

2. Subsequent runs → Serial-based​

{
  "beginSerialNo": lastSavedSerial,
  "endSerialNo": lastSavedSerial + 29
}

Then I loop:

• Increment serial range OR searchResultPosition
• Collect results
• Track all returned serialNo
• Log missing ones like this:

$expected = range($begin, $maxRetrieved);
$missing = array_diff($expected, $retrieved);

Issue Details​

1. I consistently see gaps in serial numbers, e.g.:

1001 
1908
...

1. These gaps are:

• Logged as missing in my system
• Sometimes not visible in device Web UI either
• Sometimes appear later (inconsistent)

Questions​

1. Are serialNo values guaranteed to be continuous in Hikvision devices?
   • Or are gaps expected due to internal behavior?
2. Is it safe to rely on:beginSerialNo / endSerialNo for pagination?
3. Would switching to time-based pagination only be more reliable?
4. Does using:major = 0 (ALL) cause pagination to be filled with unrelated events (alarms, system logs), thus hiding access events?
5. Has anyone experienced:
   • Database gaps
   • Missing records via API but not UI (or vice versa)

Code Snippet (Core Loop)​

Initial Request Body​

$body = [
    'AcsEventCond'=> [
        "searchID" => $this->generateGUID(),
        "searchResultPosition" => 0,
        "maxResults" => 30,
        "major" => 0,
        "minor" => 0,
    ]
];

Then incrementing position or serial range in a loop.

Serial-Based (Subsequent Runs)​

$body['AcsEventCond']['beginSerialNo'] = (int)$intSerial;
$body['AcsEventCond']['endSerialNo'] = (int)$intSerial + 29;

Then:

$intPageBeginSerial += 30;

$body['AcsEventCond']['beginSerialNo'] = $intPageBeginSerial;
$body['AcsEventCond']['endSerialNo'] = $intPageBeginSerial + 29;

$body['AcsEventCond']['searchResultPosition'] = 0;

Then incrementing position or serial range in a loop.

Looking for Advice​

If you've worked with Hikvision ISAPI:

• How do you reliably paginate logs?
• Do you trust serialNo at all?
• Best practice to avoid missing records?

 

[trempa92]

The serialNo is not recomended to validate you received all events. And you will see that each access controller/Terminal have different specsheet for max event capacity. Once it reaches max it will not increase beyond that number, it will start from 1 again.
Meaning you can have duplicates serialNo after a while of usage.
Also not all major/minor are public for API, there are internal stuffs that share serialNo incremental.


What i would do next:

POLLING - Not recommended:

Track time of lastly received event and use that time as a starting point for max results 30. Then take starting time from last event in the list again and loop it continuously. You can search by time from/till.
Add a deduping logic if you get 2 events at same time and same eventype.

REALTIME(RECOMENDED):
Have an HTTPListener or HTTPContext , set HttpHost setting on device to directly push POST events toward your service. This option support ANR, meaning if your service is unavailable of device went offline. It will push all stale events until it reaches current time. So you dont lose anything. Just parse what you need and you dont bother how to get all, as it will be pushed to you.

I will attach video so you can see how listener works for authenticate/denied major 5 events

In this case i used QR code authentication (Card number = Generated QR) So Authentication its like trying with card

 

[mhamed1]

Thanks a lot for the detailed explanation — this really helps clarify how Hikvision behaves in practice, especially around serialNo, wrapping, and shared internal counters.

The recommendation about using time-based polling with overlap + deduplication, and especially the real-time HTTP listener (push / ANR), makes a lot of sense as a production approach.

Do you have any official documentation or references for these ?

I’d like to review the official specs so I can implement it correctly and avoid relying on undocumented behavior.

Thanks again for your help.

 

[trempa92]

Official documentations are only given to those who register and sign NDA at tpp.hikvision.com

Due to signed NDA i cannot share any downloaded documents.

But i can help and guide you of you stuck somewhere

 

[trempa92]

There are roughly 8 ways how to get events.

3 Via LAN
2 via ISUP (Device registers on Backend server)
2 via Hikpartnerpro cloud open api (Device registers on Hik partner pro installer cloud, (appkey,appsecret))
2 via Hik connect open api (Device registers on HikConnect end user cloud, (appkey,appsecret))

Hpp and hc openapi advantages are that you can have remote devices without port forwarding

Isup requires server port forward not remote sites