Introduction

This documentation is intended to facilitate the process of integration with ControliD's access control line devices.

Here it is described how to carry out communication through its API, how to perform operations from user registration to identification or consultation of records. In addition, it includes examples of requests and responses for each operation presented.

Control iD's access devices offer a modern communication interface through an API (Application Programming Interface) based on TCP/IP (Ethernet) with a REST architecture. This makes integration simple and independent of the operating system or programming language used.

Two modes of operation are offered for the API: Standalone and Online (Pro or Enterprise), all in a REST API.

Code examples and requests

In Control iD's GitHub repository, code examples are available in the following languages:

  • C#
  • Delphi
  • Java
  • NodeJS
  • Python

Code examples: https://github.com/controlid/integracao/tree/master/Controle%20de%20Acesso

Most of the examples in this documentation were written in JavaScript, using the jQuery library. To test them, access the device's IP address in a web browser and use its developer tools to make requests.

All provided examples can be verified by copying their code and pasting it into the development tools console. In addition, many request examples are available in our shared collection via Postman:

Examples of HTTP requests: https://documenter.getpostman.com/view/10800185/2s9YJgSKm2

Operating modes

The possible interactions between server and access control terminal depend on the operating mode in which it works. The three operating modes described in Introduction to Operating Modes can be divided into two categories: standalone or online.

Standalone device:

  • Standalone Mode: identification and authorization on the terminal (recommended)

Online device:

  • Pro Mode: identification on the terminal and authorization on the server
  • Enterprise Mode: identification and authorization on the server

In a solution developed for terminals in autonomous operating mode (standalone), communication will take place unilaterally from the server to each terminal and must be concerned with keeping user data and access rules up to date.

When the solution is developed using terminals in any of the online modes of operation, communication occurs in both directions, as the logic of the authorization and identification processes will be on the server or partially on the server.

The requests sent by the device when it is in some online mode are described in Online Identification Events

Monitor

In all operating modes described above, to monitor asynchronous events emitted by the device, it will be necessary to use the services provided by the Monitor.

Monitorable asynchronous events include: change in access logs and alarm logs, remote enrollment of card and biometrics, turnstile turns, the opening of doors, and changes in the operating mode (e.g. entering and exiting in standard or contingency operation).

The requests sent by the device from the Monitor are described in Introduction to the Monitor.

Push

In this proactive communication mechanism, the device periodically sends HTTP requests to the server in search of commands to be executed.

When there is nothing to be done by the device, the server must send an empty response. Otherwise, the server must respond to the command to be performed and the corresponding parameters.

After the device executes the command read from the server, it sends a new request containing the result of the operation. An empty response is expected for this request, which terminates the activity until the next search.

The requests sent by the device as well as the responses to Push commands are described in Introduction to Push.