API Integration of Access Control Systems, Intercoms, and Barriers

A Brand Guide for AI Video Surveillance, Automation, and Access Management
Modern AI video surveillance rarely works well on its own. The most useful scenarios begin when the detection of a person, face, license plate, or alarm event immediately triggers an action in SmartVision: opening a door, raising a barrier, activating an intercom, sending an event to the log, moving a PTZ camera to a preset, or notifying security. That is why, when choosing equipment, it is no longer enough to look only at hardware quality.
What matters much more is whether the brand has a proper external interface, whether a door can be opened over HTTP, whether events can be received, whether SIP and RTSP can be used, and how easily all of this can be connected to AI video surveillance rules.

There comes a moment in almost every serious video surveillance project when the camera is no longer expected to just watch quietly from the wall like a retired guard with a thermos and opinions. At some point, it is asked to do something useful. A face is recognized and the door should open. A license plate is detected and the barrier should rise. A person appears in a restricted area and the system should alert security, lock an access point, or switch a PTZ camera to the right preset. This is where the romance of smart infrastructure collides with the dry but very important question of integration. Not every brand that looks polished in a brochure is equally pleasant when the time comes to connect it to an AI rule engine, a VMS, or a custom automation workflow. Somewhere the vendor gives you a normal API and a clean command structure. Somewhere you get a respectable stack of server interfaces. And somewhere the official integration path exists, but behaves like a secret society with documentation hidden behind portals, partner accounts, and ceremonial logins.
Below is a practical guide to brands that are genuinely relevant for API integration with AI video surveillance, intercoms, access control, and vehicle entry automation. Not as a glossy catalog, but as an engineer’s field note: what kind of commands exist, how integration usually looks, and which brands are friendliest when the system needs to stop watching and start acting.

Axis

Axis is one of the most convenient options for integration, especially when a unified stack is needed for cameras, intercoms, and access control. The brand provides the VAPIX Physical Access Control API and Intercom API, which allow integration with doors, relays, statuses, users, events, and call panel logic. This is not the rustic style of “just hit a strange URL and pray”, but a proper vendor API with defined operations for access control.
  • Door opening over HTTP: yes.
  • Event retrieval: yes.
  • Webhooks: not the primary mechanism in the classical sense. API requests, events, and WebSocket or service interfaces are more commonly used.
  • SIP: yes, for intercoms.
  • RTSP: yes, for Axis video devices.
How easy it is to connect with AI rules: very easy. This is one of the best brands for scenarios such as “face detected -> open door”, “person in zone -> switch intercom to the required mode”, or “alarm detected -> open or lock door, or activate I/O”.
Typical command logic revolves around actions such as unlock door, lock door, access door, and retrieve door state. A real-world integration usually looks like this: the analytics system detects a face or rule condition, then sends a command to Axis to unlock or grant access to the relevant door.
A typical example of the request structure looks like this:
{
"tdc:UnlockDoor": {
"Token": "myDoor"
}
}
And for temporary passage:
{
"tdc:AccessDoor": {
"Token": "myDoor"
}
}
Suitable for: offices, business centers, warehouses, facilities with a unified video and access control stack, integration with VMS and automation rules.

2N

2N is one of the most convenient brands specifically for IP intercoms and door stations with external integration. It has a well-known HTTP API that allows control of locks, relays, inputs, and a number of device functions. If Axis feels like a disciplined enterprise engineer, 2N feels like the intercom vendor that actually remembered people would want to automate things.
  • Door opening over HTTP: yes.
  • Event retrieval: yes, within the API and device logic.
  • Webhooks: not the main focus in explicit form. Direct HTTP API and the built-in event logic of the intercom are used more often.
  • SIP: yes.
  • RTSP: depends on the model and scenario, but video streaming and integration with the video ecosystem are supported by 2N.
How easy it is to connect with AI rules: very easy. If the AI system can call an HTTP endpoint, 2N is an excellent fit for scenarios like “face recognized -> open door”, “unknown person -> initiate call”, or “alarm -> activate relay”.
With 2N, the most useful commands are refreshingly concrete. You can switch relays, check switch status, grant access through access points, and work with logs and event subscriptions. In plain English, this means an AI system can trigger a lock, activate a relay, open an entry point, or pull event history without having to invent black magic.
Typical examples look like this:
GET /api/switch/ctrl?switch=1&action=on
Holding a relay may look like this:
GET /api/switch/ctrl?switch=2&action=hold
Checking status:
GET /api/switch/status
Granting access to an entry point:
GET /api/accesspoint/grantaccess?id=1
And if a project needs event-based behavior rather than raw relay control, the log subscription and pull mechanisms can be tied into a rule engine. For AI-driven entry scenarios, 2N is one of the easiest brands to work with.
Suitable for: residential complexes, business centers, premium offices, intercom integration with VMS, AI, and applications.

BAS-IP

BAS-IP is focused on IP intercom systems and external integration through Open API JSON. It also supports SIP and RTSP, which makes the brand convenient where the goal is not just to open a door, but to embed the intercom into the overall digital system of a building or residential complex.
  • Door opening over HTTP: yes, through Open API JSON.
  • Event retrieval: yes.
  • Webhooks: depends on the platform and implementation, but basic API integration is available.
  • SIP: yes.
  • RTSP: yes.
How easy it is to connect with AI rules: easy. It is particularly well suited for entrance groups, gates, residential complexes, and sites where AI analytics should trigger intercom actions or owner notifications.
Typical practical patterns in such integrations include operations like:
POST /api/door/open
GET /api/panel/status
GET /api/events
POST /api/call/action
The exact naming depends on the environment, but the integration logic is clear. BAS-IP is useful where the system needs to respond to AI detections at entry points, gates, or shared access zones, and where intercom behavior must be coordinated with the broader digital infrastructure of the property.
Suitable for: apartment buildings, residential complexes, office buildings, business centers, integration of intercom systems with mobile applications and video surveillance.

Akuvox

Akuvox supports HTTP API integration with third-party systems. In most cases, this mode must be enabled separately in the device web interface. It is not the most luxurious option in terms of documentation, but the brand does offer external control capabilities, which makes it a serious candidate for integration projects. It is also a classic example of a brand where the API exists, but the first real integration task is often making sure someone actually enabled it.
  • Door opening over HTTP: yes.
  • Event retrieval: partially yes, depending on the model and integration scheme.
  • Webhooks: not everywhere and not as a default mechanism.
  • SIP: yes, the brand offers SIP-oriented intercom systems.
  • RTSP: support depends on the model, though video integration is commonly found in IP intercoms and monitors.
How easy it is to connect with AI rules: moderately easy. It works well for basic scenarios, but in terms of convenience and integration transparency it usually trails behind 2N and Axis.
Once enabled, the platform can be approached in the familiar style of status, relay, unlock, and event-oriented commands. Typical patterns include requests like:
GET /api/status
POST /api/relay
POST /api/unlock
GET /api/events
The precise command set depends on the model, but the overall picture is good enough for architectural planning.
Suitable for: intercom systems, residential and office sites where an IP intercom with external control is needed without locking into a fully closed ecosystem.

Suprema

Suprema is strong in biometrics and access control. External integration is usually built through the BioStar 2 platform and its Local API. This layer allows work with users, events, access rights, logs, and a number of related functions. Suprema enters the picture from the access control and biometrics side. It is less about intercom charm and more about identity, policy, time attendance, and serious server-based access logic.
  • Door opening over HTTP: yes, at the platform and API level.
  • Event retrieval: yes.
  • Webhooks: not a major focus. Integration is more often built through API and server-side logic.
  • SIP: no, this is not the brand’s profile.
  • RTSP: not a core feature of the platform.
How easy it is to connect with AI rules: easy, if the integration goes through the BioStar 2 server. It is excellent for scenarios like “face recognized by camera -> verify against access database -> open door -> log event”.
The good news is that the integration flow is structured. The first step is login. The second step is everything else. That sounds obvious, but in industrial software even obvious things deserve applause.
A typical entry point looks like this:
POST /api/login
Content-Type: application/json
With a request body in this style:
{
"User": {
"login_id": "admin",
"password": "password"
}
}
After authentication, the session is used for subsequent requests involving users, events, doors, devices, or other platform entities. Suprema is especially useful when the workflow is not just “camera saw face, door opens,” but “camera saw face, identity is verified against access policy, event is logged, passage is granted, and the result is recorded properly.”
Suitable for: enterprises, offices, sites with biometrics, time attendance, and strict role-based access control.

Paxton

Paxton Net2 has long been appreciated for its clear integration through Web API and SDK. It allows work with doors, users, events, operators, time zones, and commands. This is one of those brands where integration feels like an intended part of the product rather than an afterthought.
  • Door opening over HTTP: yes, through the Net2 Web API.
  • Event retrieval: yes.
  • Webhooks: not usually highlighted as the main mechanism. Integration is more often based on API and server-side logic.
  • SIP: no.
  • RTSP: no, this is not the brand’s focus.
How easy it is to connect with AI rules: very easy. It is well suited for employee access, visitor scenarios, alarms, passage logs, and integration into a general automation engine.
Publicly, Paxton tends to present its API more as a capability matrix than as a giant friendly cookbook. That means the shape of the system is clear, but the exact endpoint details usually depend on the deployed environment and documentation available to integrators. Even so, the logic is easy to understand.
Typical integration families include requests like:
GET /api/doors
GET /api/events
GET /api/users
POST /api/commands
PUT /api/users/{id}
DELETE /api/users/{id}
That is enough to understand the flavor of the platform. The system is designed around the expected business entities: doors, users, events, commands, permissions.
Suitable for: offices, schools, commercial facilities, sites with external IT systems and custom logic.

Gallagher

Gallagher belongs to the heavier, enterprise-grade class of access control systems. It provides a REST API for statuses, alarms, events, cardholders, inbound events, and other entities, as well as a cloud API Gateway. For large sites and centralized control, it is a very serious option.
  • Door opening over HTTP: yes, through REST API and related control or override mechanisms.
  • Event retrieval: yes.
  • Webhooks: inbound events and integration scenarios exist, but the exact model depends on the Command Centre architecture.
  • SIP: no.
  • RTSP: no, this is not the brand’s profile.
How easy it is to connect with AI rules: easy at the server integration level, but this is already enterprise territory. It may be too heavyweight for a small site, but very appropriate for a large one.
Gallagher sits in a heavier corporate category. This is not a light little access system for a cozy office with two doors and a coffee machine. This is infrastructure-grade territory, where alarms, events, monitoring, notes, workflows, and central command logic matter.
Typical request patterns in this world include:
GET /api/events
GET /api/alarms
GET /api/events?from=...&to=...
POST /api/alarms/{id}/acknowledge
POST /api/alarms/{id}/notes
This tells you a lot about what Gallagher is for. It is less about casually flicking a relay and more about structured event management at scale. If an AI rule engine needs to escalate incidents, connect detections to alarm workflows, or feed a situation center with meaningful security events, Gallagher makes sense.
Suitable for: large enterprises, campuses, infrastructure facilities, sites with SOCs and situation centers.

Rosslare

Through AxTraxPro, Rosslare provides a REST API and also mentions GraphQL API and SDK. This makes it possible to work with users, access groups, credentials, events, and automation. The brand is not discussed as loudly as some competitors, but in terms of integration it is very capable.
  • Door opening over HTTP: yes, through the platform API.
  • Event retrieval: yes.
  • Webhooks: less emphasized directly, with REST API being the main path.
  • SIP: no.
  • RTSP: no, this is not the brand’s focus.
How easy it is to connect with AI rules: easy. For projects with an external rule engine and AI scenarios, Rosslare is quite convenient, especially when API access to users and events is required.
In practical terms, the integration model typically revolves around operations like these:
GET /api/users
POST /api/users
GET /api/events
GET /api/access-groups
POST /api/credentials
The exact URI naming can vary depending on the platform version, but the architectural point is clear. Rosslare exposes the right kinds of entities for server-side automation. If SmartVision or another analytics platform needs to create logic around credentials, users, access groups, or event handling, Rosslare is very workable.
Suitable for: offices, enterprises, access systems with custom integration and server-side automation.

Hikvision

Hikvision is interesting because access control, intercom systems, and video all live inside one large ecosystem. External integration is usually built through ISAPI, ISUP, and platforms such as HikCentral. It is not the most open world imaginable, but there is an official external interface, and for facilities already built on Hikvision this is often the most rational path.
  • Door opening over HTTP: yes, through ISAPI and platform-level mechanisms.
  • Event retrieval: yes.
  • Webhooks: usually not the main focus. Integration is more often built through API, the platform, and event subscription within the ecosystem.
  • SIP: supported in intercom solutions and related subsystems, but depends on the product line.
  • RTSP: yes, for video and analytics.
How easy it is to connect with AI rules: very easy if the entire site already uses Hikvision. If many third-party systems must be mixed, convenience depends on the specific architecture.
The integration patterns typically include access-control objects, user information, event subscriptions, and device-related queries. Examples often look like this:
GET /ISAPI/AccessControl/Door
GET /ISAPI/AccessControl/UserInfo
GET /ISAPI/Event/notification/alertStream
POST /ISAPI/Event/notification/subscribeEvent
The exact details depend on the product line, but the principle is straightforward. Hikvision provides an official external interface, and when video, intercoms, and access control are already living under the same brand umbrella, that can be very efficient.
Suitable for: facilities where the Hikvision ecosystem is already installed and there is a need to combine video, intercoms, access control, and centralized management.

CAME

When it comes to barriers and parking automation, the choice of brands with official external API integration becomes much narrower. CAME offers CAME Connect and a parking platform with web APIs and web services. For barriers, gates, and parking scenarios, it is one of the most visible brands where integration is officially declared at the vendor level.
  • Door or barrier opening over HTTP: yes, within CAME Connect and the parking platform.
  • Event retrieval: yes.
  • Webhooks: depends on the specific service and implementation, but web services and API are available.
  • SIP: no.
  • RTSP: not applicable in the classic sense, since this is primarily barrier and parking automation equipment.
How easy it is to connect with AI rules: easy for parking scenarios, LPR, entry and exit control, and opening gates or barriers based on events from VMS or AI analytics.
When the conversation shifts from doors and intercoms to barriers, gates, and parking automation, the shortlist of brands with meaningful official integration becomes much shorter. CAME stands out because it offers a recognizable connected platform and API-oriented services for automation and parking scenarios.
Typical integration patterns in this domain include:
POST /api/barriers/{id}/open
POST /api/gates/{id}/open
GET /api/barriers/{id}/status
GET /api/parking/events
That is exactly the sort of interface an AI video surveillance platform wants to see when it detects a plate number, receives a permit decision, or triggers vehicle-entry logic.
Suitable for: parking areas, residential complexes, logistics, checkpoints, and facilities with vehicle entry automation.

Quick reference table

Examples of GET and POST Commands for API Integration

In real projects, integration usually becomes much less mysterious the moment everything is reduced to a few simple HTTP requests. Behind all the serious words like “automation”, “orchestration”, and “event-driven access control” there is often a very ordinary exchange: one system sends a request, another system says “accepted”, and the door either opens heroically or remains shut with corporate dignity.
The simplest scenario is a GET request. It is commonly used when the external device accepts commands directly through URL parameters, or when the software needs to request a current status from the device or controller.
A typical GET request for reading device status may look like this:
GET /api/device/status HTTP/1.1
Host: 192.168.1.50
Authorization: Bearer YOUR_TOKEN
Example URL:
http://192.168.1.50/api/device/status
Example response:
{
"device": "door_controller_1",
"status": "online",
"door": "closed",
"relay": "off",
"timestamp": "2026-03-15T12:05:00Z"
}
A GET command may also be used to trigger a simple action on devices that support command-style URLs:
http://192.168.1.50/api/openDoor?id=1
Or:
http://192.168.1.50/relay/trigger?channel=2&state=on
This approach is easy to implement and easy to debug. It is also old-fashioned in the honorable engineering sense: crude, effective, and often still alive in production ten years later.
A POST request is more common in modern REST API integrations. It is used when the command must include parameters in the request body, when an event must be sent to another system, or when structured JSON payloads are required.
A typical POST request for opening a door may look like this:
POST /api/access/open HTTP/1.1
Host: 192.168.1.60
Authorization: Bearer YOUR_TOKEN
Content-Type: application/json
Request body:
{
"doorId": 1,
"reason": "face recognized",
"source": "AI surveillance",
"duration": 5
}
Example response:
{
"success": true,
"message": "Door open command accepted",
"eventId": "evt_458921"
}
A POST request for activating a relay may look like this:
POST /api/io/relay HTTP/1.1
Host: 192.168.1.70
Authorization: Bearer YOUR_TOKEN
Content-Type: application/json
{
"relay": 2,
"action": "pulse",
"pulseMs": 3000
}
Example response:
{
"success": true,
"relay": 2,
"state": "triggered"
}
If SmartVision or another AI video analytics platform needs to send an alarm event into a third-party access control or automation system, the request may look like this:
POST /api/events HTTP/1.1
Host: integration-server.local
Authorization: Bearer YOUR_TOKEN
Content-Type: application/json
{
"eventType": "person_detected",
"cameraId": 14,
"cameraName": "Warehouse Gate",
"objectType": "person",
"confidence": 0.97,
"timestamp": "2026-03-15T12:10:22Z",
"action": "notify_security"
}
Example response:
{
"accepted": true,
"queueId": "q_10294"
}

Examples of REST API Endpoints

In practice, most integrations between AI video surveillance, intercoms, barriers, and access control systems are built around a small set of common REST API patterns. Vendors may use different naming styles, but the logic is usually familiar enough that after working with three brands, the fourth stops looking mysterious and starts looking like a relative.
Read device status:
GET /api/devices/{id}
Example:
GET /api/devices/door-controller-1
Example response:
{
"id": "door-controller-1",
"type": "access_controller",
"online": true,
"lastSeen": "2026-03-15T12:00:00Z"
}
Get event list:
GET /api/events?from=2026-03-15T00:00:00Z&to=2026-03-15T23:59:59Z
Example response:
[
{
"id": "ev1001",
"type": "door_open",
"doorId": 1,
"timestamp": "2026-03-15T08:45:10Z"
},
{
"id": "ev1002",
"type": "access_denied",
"doorId": 3,
"timestamp": "2026-03-15T09:02:44Z"
}
]
Open a door:
POST /api/doors/{id}/open
Example:
POST /api/doors/1/open
Request body:
{
"trigger": "AI rule",
"operator": "SmartVision",
"timeout": 5
}
Lock a door:
POST /api/doors/{id}/lock
Unlock a door:
POST /api/doors/{id}/unlock
Activate intercom relay:
POST /api/intercom/relay
{
"panelId": 2,
"relay": 1,
"action": "pulse"
}
Move PTZ camera to preset:
POST /api/ptz/preset
{
"cameraId": 12,
"preset": 4
}
Send event from AI system to external platform:
POST /api/integration/events
{
"event": "license_plate_detected",
"plate": "ABC1234",
"cameraId": 7,
"zone": "entry_gate",
"timestamp": "2026-03-15T12:15:00Z"
}
Request current access state:
GET /api/access/state?doorId=5
Example response:
{
"doorId": 5,
"state": "locked",
"alarm": false,
"lastEvent": "closed"
}

Why These Examples Matter in Real Projects

From an integration point of view, the most valuable thing is not whether the vendor uses the most fashionable API vocabulary of the season. What matters is whether the system can do a few concrete things reliably: accept a command, return a status, provide events, authenticate requests, and behave predictably when something goes wrong. A glamorous API that breaks under load is still just a decorative problem.
In the real world, the most common AI video surveillance scenarios usually come down to a few recurring REST patterns:
face recognized -> send POST command to open a door
vehicle plate recognized -> send POST command to raise a barrier
person detected in restricted zone -> send POST command to lock access point or notify security
visitor detected at entrance -> send GET or POST request to intercom or call logic
alarm event received from third-party device -> GET or POST the event into the VMS or automation engine

A Practical Note on Authentication and Security

Even the simplest HTTP integration should normally include authentication. Depending on the vendor, this may be implemented with Bearer tokens, Basic Auth, API keys, session cookies, or signed requests.
Examples:
Authorization: Bearer YOUR_TOKEN
or
Authorization: Basic BASE64_LOGIN_PASSWORD
or
X-API-Key: YOUR_API_KEY
If the device happily opens a door after receiving an unauthenticated request from anywhere on the network, that is no longer integration elegance. That is an invitation to chaos dressed as convenience.

A Practical Note on Response Codes

Most REST APIs also use standard HTTP response codes:
  • 200 OK for a successful request
  • 201 Created when a new event or object is created
  • 400 Bad Request when parameters are invalid
  • 401 Unauthorized when authentication failed
  • 403 Forbidden when the command is understood but not allowed
  • 404 Not Found when the object or endpoint does not exist
  • 500 Internal Server Error when the remote system has decided to have a difficult day
For integration with AI rules, it is useful when the external system returns not just a status code, but also a structured JSON response with a success flag, message, and event or transaction identifier.

What Is Easiest to Connect with AI Video Surveillance Rules

If the goal is the simplest path for AI video surveillance scenarios, the brands can be divided like this. For intercoms and door stations, the easiest to connect are 2N, Axis, and BAS-IP. They have good external interfaces, support HTTP or API control, and Axis and 2N also provide very convenient logic for events and I/O. For access control systems, the easiest to integrate are Axis, Suprema, Paxton, and Rosslare. If enterprise scale and deep server-side integration are needed, Gallagher is a strong fit. For barriers and parking, CAME is the most straightforward option on this list.

Brief Practical Assessment

If the most convenient brand is needed for the scenario “AI detected something -> HTTP command -> open door”, then the top group includes 2N, Axis, BAS-IP, Paxton, and Suprema. If a brand is needed that works especially well with a unified video and access ecosystem, then Axis and Hikvision stand out. If a barrier or parking control setup with official integration is required, CAME looks like the clearest option from the shortlist.
Once the dust settles, the integration landscape is not as chaotic as it first appears. Some brands make life easier by exposing very direct command models. Axis and 2N are especially strong here. Some brands are better understood as server platforms rather than device command endpoints, which is where Suprema, Gallagher, Rosslare, and Paxton often shine. Hikvision works particularly well when the site is already built around its own ecosystem. CAME matters when vehicles enter the story and barriers become actors instead of scenery.
For the simplest AI automation scenario, the gold standard remains something like this: detection happens, rule is matched, authenticated request is sent, action is confirmed, event is logged. No mystical abstractions. No decorative dashboards pretending to solve the problem. Just reliable machine-to-machine behavior. And that, in the end, is what good API integration in security really is. Not a fashionable buzzword. Just a clean way to make one box tell another box to do its job, without drama, without ritual, and preferably without someone having to run downstairs with a key.

Video Surveillance