Introduction

Use VAPIX® Entry Service API to check if the API is supported. Services and namespaces are listed in the following table.

Supported events, action templates and recipient templates are product dependent.

The administrative user distribution (AUD) is an underlying layer to the existing Administrative User interfaces.

Actions on AUD, that is, add, update and remove, will be propagated through the system, if having multiple door controllers in a network as described in section Connection service, and the accounts will be available on all peers in the door controller network.

Administrative users have three levels of rights (viewer, operator and admin) and where admin level is required for all actions. The lower levels exist but as they can not execute any actions they are not fully supported by AUD.

When executing actions on multiple ONVIF^TM administrative users, the execution is faster when the administrative users are given in a batch in one call than given one by one in sequence.

The door controller has the following default administrator account:

For security reasons, it is strongly recommended to change the password. Change the password, preferably using HTTPS, when logging in to AXIS Entry Manager for the first time, or by using VAPIX® General System Settings API.

The access control system (aka PACS system) has different types of users, for example:

1. User. A PACS user, also known as credential holder or card holder. This user is a physical person who uses the system and the hardware to get access to doors in rooms and buildings.

2. Administrator. A system administrator who uses AXIS Entry Manager to manage the access control system, its door controllers, connected devices, users, and schedules. This user always belongs to the Administrator user group.

3. PACS API user. A client such as an access management system that makes VAPIX® or ONVIF^TM calls to the door controller.

The code examples in the API documentation are available in JavaScript Object Notation (JSON) and in SOAP. Use the buttons to switch between JSON and SOAP.

JSON examples

{"AccessController":[
  {"AccessPoint": [""],
    "Description": "",
    "Name": "Axis-00408c184bdb AccessController",
    "token": "Axis-00408c184bdb AccessController"} ]}

{"pacsaxis:GetAccessControllerList":{}}

{"AccessController": [ {
    "token": "Axis-00408c184bdb AccessController",
    "Name": "Axis-00408c184bdb AccessController",
    "Description": "",
    "AccessPoint": []
  } ]
}

$ curl --anyauth "http://<user>:<password>@<ip>/vapix/pacs" -s -d’{"pacsaxis:GetAccessControllerList":{}}’
{
  "AccessController":
    [
      {
        "token": "Axis-00408c184bdb AccessController",
        "Name": "Axis-00408c184bdb AccessController",
        "Description": "",
        "AccessPoint": []
      }
    ]
}

SOAP examples

<pacsaxis:AccessController token="Axis-00408c184bdb AccessController">
  <pacsaxis:Name>Axis-00408c184bdb AccessController</pacsaxis:Name>
  <pacsaxis:AccessPoint></pacsaxis:AccessPoint>
  <pacsaxis:Description></pacsaxis:Description>
</pacsaxis:AccessController>

$ cat GetAccessControllerList.soap
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope ...>
<SOAP-ENV:Header>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
  <pacsaxis:GetAccessControllerList/>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
$ curl --anyauth "http://<user>:<password>@<ip>/vapix/services" -s
  -d@GetAccessControllerList.soap
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope ...>
<SOAP-ENV:Header>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
  <pacsaxis:GetAccessControllerListResponse>
    <pacsaxis:AccessController token="Axis-00408c184bdb AccessController">
      <pacsaxis:Name>Axis-00408c184bdb AccessController</pacsaxis:Name>
      <pacsaxis:Description></pacsaxis:Description>
    </pacsaxis:AccessController>
  </pacsaxis:GetAccessControllerListResponse>
</SOAP-ENV:Body>

Common data fields

Common data structure types

Set requests are used to add new data items as well as to replace existing items. If the token field is left empty or if the provided token does not exist, the set request will create a new data structure on the door controller. If the provided token exists, data in the existing data structure will be replaced by the data provided in the set request. The response to a set request is a list of existing tokens.

As discussed in section Common data structure types, most entities are represented by two data types. A set request will create or replace both data types as both are required.

Get requests are used to retrieve data from the door controller. The response is a list of available data items. Data elements can, in most cases, be retrieved either as a single data item or as a list of data items.

A single data item is retrieved by specifying the token in a get request named according to the pattern Get<DataType>.

A data list can be retrieved using Get<DataType>List or Get<DataType>.

If no parameters are specified, Get<DataType>List returns a list of all available data items. To limit the output, the following parameters can be used:

• Limit: Maximum number of returned data elements.

• StartReference: This parameter is used to continue fetching data from the last position and enables iterations over large data sets in smaller chunks. A client shall not make any assumptions on StartReference contents and shall always pass the NextStartReference value returned from a previous request to continue fetching data. A reference should only be used once.

If the full data set can not be returned in one call or if Limit is specified, a NextStartReference will be returned together with the data chunk. The NextStartReference can be used to continue fetching data from the last point.

Get<DataType> returns a list of data types matching the tokens of the supplied list of tokens. The input parameter called Token will be used to filter returned elements, but, if left empty, no elements will be returned.

Retrieving lists with too many data items might affect performance. It is recommended to use the parameters to limit the output.

The door controller will dispatch events. By creating pull-point subscriptions, it is possible to listen to events in real time. Refer to the ONVIF^TM documentation for details.

The Event Logger Service provides logging of events, see section Event logger service. Event examples in the documentation are written in the format received when using the API request axlog:FetchEvents.

The Universally Unique Identifer (UUID) is used to identify door controllers in a network. Each door controller has a unique UUID. In data structures that represent configurations for a specific door controller, for example, ID point configuration, door configuration and access controller configuration, the UUID is a data field.

If the UUID data field is left empty, the UUID of the door controller to which the request is sent will be inserted automatically. That is, as long as configurations are sent to the intended door controller, the UUID does not need to be specified.

If several door controllers are connected in a door controller network, requests to get or set configurations on one door controller can be sent to any door controller in the network as long as the UUID is specified. The configuration will be read from or set to the door controller that matches the specified UUID.

To find the UUID:s of the door controllers in the network, use aconn:GetPeerList from the Connection Service, see Connection service. The following example shows the request and response. The response lists all door controllers in the network, including the door controller to which the request was sent.