Camio User Guide for Genetec: Tailgating detection and real-time video search

This Camio User Guide covers:

  1. Overview of Camio with Genetec
  2. Mapping cameras to Genetec door
  3. Enabling Tailgating Notifications
  4. Camio Setup for Genetec
  5. Genetec Setup

Overview of Camio with Genetec

Fast visual verification and access event detection

Camio enables fast search and alerts on events like access granted, door open while lock secure, and tailgating. Skip to Linux or Windows installation and resource requirements.

Camio counts the number of people that pass through the door to compare that number to the actual number of Genetec access granted events. If those counts don't match, then the video is annotated with "tailgating" unauthorized access. This video illustrates tailgating detection as the floor plane tiles turn red when the second person enters after only one access granted event:

Works with existing cameras

Setup takes less than 15 minutes. Each camera is mapped to a Genetec door so that events from those doors annotate the video from that camera. You configure the on-premise Camio Gateway with the credentials required to subscribe to Genetec access control events.

Mapping cameras to doors

The first step is to associate your Genetec doors with any cameras that can see them.

  1. Generate your Camio Authorization token to be used by the Camio Gateway to annotate video with incoming access control events.
    1. Sign-in as the Camio account manager and press the Generate button at
      • Either the account owner or a guest with Can Manage permission can generate the token
    2. Copy the token immediately after you generate it, since you will not be able to retrieve it again later.
    3. Paste the token into your Camio Gateway configuration as the "camio_auth_token" valuemceclip0.png
    4. Select the door from the dropdown list next to each camera that has a view of people entering the door and press SaveScreenshot_2022-12-14_at_5.25.39_PM.png

Note: If you see a message "No integration settings found..." that means integration settings have never been saved for this account. Configure the settings and hit save. When you reload the page, the message should be gone.

Removing Camera to Door Mappings

You can update which cameras you have mapped to your doors on the settings page at To remove the currently mapped door, click on the door in the dropdown list or click the x next to the door's name:


Alternatively, select a new door.

If your camera was mapped to an old door that is no longer in your list of Genetec doors, the dropdown may appear blank:


To remove the old door, select and then deselect a new door from the dropdown. This will clear the old door. The dropdown should then look like this:


Make sure you click Save to confirm the changes.

Enabling Tailgating Notifications

Optionally, enable Camio to send notifications via email when a tailgating incident occurs. To enable this feature, set a tailgating email template. You can customize the template or select Use Default to use the default template. 


Read more about setting up tailgating alerts here.

Camio Setup for Genetec

The Camio Gateway subscribes to Genetec access control events in order to annotate the video associated with each event.

Camio Gateway Installation

The Camio Gateway runs as a Kubernetes deployment installable with Helm, which can run on any host machine (e.g. Linux, Windows) that can make calls to the Genetec Web SDK API. If your firewall restricts the sites contacted, then please see firewall rules.

Quick Install via Helm

Detailed instructions for installing any of the Camio PACS Gateway deployments through Helm can be found at the Camio User Guide for setup and deployment of Camio PACS Gateways. The following instructions will be a brief overview of setting up with Helm, specific to the Genetec Gateway.

1. Create your values.yaml file. The most basic values.yaml for the Genetec gateway should look like:


acs_server_ip: INSERT_SERVER_IP_HERE
acs_app_id: INSERT_APP_ID_HERE


camio_auth_token: "INSERT_CAMIO_AUTH_TOKEN_HERE"

That current version of the Camio Genetec Gateway does not support self-signed certificates. Please contact for more details if your deployment will need to use self-signed certificates.

2. Create your K8s cluster if does not exist

3. Run:

helm install camio-genetec oci:// --version 0.0.1 -f /PATH/TO/values.yaml [-n camio] [--create-namespace]

The namespace ( -n ) argument is optional and will deploy the gateway in the specified namespace. If not included, the gateway will be set up in the default namespace. Use --create-namespace if the namespace you want to use does not currently exist.

4. Confirm that your helm installation was successful by running:

kubectl get pods [-n camio]

The output should look something like:

NAME                          READY STATUS  RESTARTS AGE
genetec-camio-XXXXXXXXX-XXXXX 1/1 Running 0 9s

If the genetec-camio pod shows as 1/1 READY and 0 RESTARTS then the gateway is up and running. If you would like more details, you can retrieve the logs for your pod by running:

kubectl logs genetec-camio-XXXXXXXXX-XXXXX [-n camio]

Camio Gateway Configuration (values.yaml file)

The configuration is divided into the following sections to organize the gateway's settings:


(Helm Key)

Description and Available Fields

Camio Config


This contains your secret Camio Authorization token obtained from used to annotate video. Example:

camio_endpoint: ""
camio_cert_enable: 'False'
camio_auth_token: "INSERT_CAMIO_AUTH_TOKEN_HERE"
camio_max_retries: 100

endpoint: 'webhooks'
queue_forward_bulk_status: 'individual'

endpoint: 'stats'
queue_forward_bulk_status: 'individual'

endpoint: 'devices'
queue_forward_bulk_status: 'individual'

endpoint: 'logs'
queue_forward_bulk_status: 'bulk'

endpoint: 'errors'
queue_forward_bulk_status: 'bulk'

Genetec Config


acs_server_ip: INSERT_SERVER_IP_HERE
acs_app_id: INSERT_APP_ID_HERE
cert_enabled: False
cert_disabled_alt_port: None
- "DoorOpenedForTooLong"
- "DoorOpen"
- "DoorManuallyUnlocked"
- "DoorUnlock"
- "DoorOpenWhileLockSecure"
- "DoorScheduledUnlock"
- "AccessGranted"

Advanced Config


forward_event_queue_interval: 5
forward_stats_queue_interval: 3600
forward_devices_queue_interval: 86400
forward_logs_queue_interval: 3600
forward_errors_queue_interval: 30
logs_queue_pull_size: 120
errors_queue_pull_size: 120
default_log_level: 'INFO'
debug_mode: "False"
max_threads_per_pagination_call: 10


Genetec Event Filter

The Camio gateway will only receive the Genetec events enumerated under genetec.acs_door_events in the Helm values. The default values are:

- "DoorOpenedForTooLong"
- "DoorOpen"
- "DoorManuallyUnlocked"
- "DoorUnlock"
- "DoorOpenWhileLockSecure"
- "DoorScheduledUnlock"
- "AccessGranted"

You can add or remove event names from the list to filter their ingestion into the Camio system.

Camio Gateway Host Hardware Requirements

The CPU and RAM required of the host machine that runs the Camio Gateway varies with the maximum throughput of access control events. This guide covers common volumes:

Max Event Rate

CPU Cores


100 events/second


300 MiB

1,000 events/second


400 MiB

10,000 events/second


400 MiB

If you are also setting up MicroK8s on your machine, MicroK8s recommends 20G disk space and 4G of memory.

Firewall Rules

During the initial setup and any updates to the deployment, you will need access to these domains:


During operation the gateway will need access to the specified camio endpoints:

Note: These rules only cover the Camio Gateway. If you are setting up K8s for the first time you may need to set up additional firewall rules.


Genetec Setup


To use the Genetec Web SDK, the following conditions are necessary:
  • SecurityCenter license must have the Web SDK option activated.
  • Security Center license must contain an SDK certificate (more details in the Authentication section below).
  • A role of type"Web-based SDK" needs to be created and running in the Security Center system, since it is not a default role.

In the Config Tool, create a new role of type Web-based SDK, and assign it to a server.  This role hosts the web service of the Web SDK API.  Refer to the Administrator Guide for more information (appropriate sections are pasted at the bottom of this document). 

Important: This role contains the Port and Base URI configuration.


The Web SDK API uses the HTTP basic authentication method. Each request must include a Security Center user and password; only native users are supported, not Active Directory users. Each request must also contain the ApplicationID of the SDK certificate. Note that this certificate is different on development and production systems.

The ApplicationId provided in the web request is matched against Security Center license SDK certificates.  The ApplicationId provided in the help file and code samples (Kxs...Nimv) is for an SDK certificate valid on demo systems only.  The related part number is GSC-SDK.

Before going in production with a Web SDK application, make sure you change the ApplicationId with the ApplicationId from the production certificate.

A production certificate is linked to a production part number, which needs to be present and visible in the Security Center license options; otherwise, the requests will be forbidden (http error 403).
The part number format typically is 'GSC-1SDK-DevelopmentCompany-Application'


To run the Web SDK role with encryption, you require the following: 

  • The computer running the service must first have a valid SSL certificate installed.
  • The use SSL option must be checked in the Web SDK configuration page in Security Center Config Tool. A group box appears. The Certificate textbox must contain the name of the certificate.
  • Finally the certificate must be bound to the port. If the Bind certificate to port option is set to Off, the binding must be done by Windows. If the option is set to On, the binding is done by the Web SDK. To use automatic binding, the certificate must be registered as a local computer personal certificate.

If SSL is enabled, the address starts with HTTPS instead of HTTP.

The WebSDK role uses the same SSL Certificate as configured for the Genetec Server in the Genetec Server Admin. When a change is made to Genetec Server's SSL Certificate, the WebSDK role will automatically detect the change and start using the newly applied certificate. 

To enable SSL in the WebSDK using Config Tool, open the task System>>Roles>>Select the WebSDK role>>properties and set Use SSL Connection “On”.

In order for the WebSDK request calls to work on client computers, the Certificate configured in the Genetec Server needs to be trusted by the client computer. This means that the Root Certificate Authority used to sign the SSL Certificate for the primary server or expansion server needs to be present in the “Trusted Root Certificate Authorities” of Windows.

If the certificate used in Genetec Server is not trusted by the client computer, you can use the Windows feature “Install Certificate” to add the Certificate to the Trusted Root Certificate Authority of Windows.


Genetec Administrator Guide

About roles

A role is a software component that performs a specific job within Security Center. To execute a role, you must assign one or more servers to host it. You can assign roles for archiving video, for controlling a group of units, for synchronizing Security Center users with your corporate directory service, and so on.

In Security Center, role entities are defined by the following:

  • Role type: Determines the specific set of functions that should be performed by the role, such as managing video units and associated video archives.
  • Role settings: Define the specific set of parameters the role should operate within, such as the retention period for the collected data, or which database the system should use.
  • Servers: The servers that should be hosting (running) this role. You can assign one or more roles to the same server, or assign multiple servers to the same role to provide load balancing and failover.

After a role is configured, you can move it to any server in your Security Center system (for example, one with a faster processor or more disk space) without having to install any additional software on that server. Moving a role to another server might cause a short pause in the role’s operations. In addition, some roles can spawn subprocesses (called agents) and execute them simultaneously on multiple servers for greater scalability.

Moving roles to other servers

You can move a role to another server without installing any additional software, for example, if the server that the role is installed on is slow or has limited disk space.

Before you begin

Make sure you have another server configured and ready to accept a new role.

What you should know

Moving a role to another server might cause a short pause in the role’s operations.

NOTE: This procedure does not apply to Archiver roles. For moving Archiver roles, see Moving the Archiver role to another server on page 568 of the Web SDK guide.

To move a role to another server:

  1. From the Config Tool homepage, open the System task, and click the Roles view.
  2. Select the role you want to modify, and then click the Resources tab.
  3. If the role requires a database, do one of the following:
    1. If the database resides on a third computer, you have nothing to change.
    2. If the database is empty, you can create it anywhere you want.
    3. If the database contains data and is residing on the current server, move the database to the new server or to a third computer.
  4. Under the Servers list, click Add an item ( ). A dialog box shows all available servers on your system.
  5. Select the substitute server and click Add.
  6. Select the current server in the Servers list and click Delete ( ).
  7. Click Apply.

Deactivating and activating roles

For maintenance or troubleshooting purposes, you can deactivate a role without affecting any of its settings and then re-activate it later.

What you should know

If you are experiencing issues with your system, sometimes it is helpful to restart a role. Roles are also deactivated so their properties can be modified.

You must have the Modify role properties privilege to deactivate a role.

To deactivate a role:

  1. From the home page, open the System status task.
  2. From the Monitor drop-down list, select Roles.
    The roles that are part of your system are listed in the report pane.
  3. Select a role you want to deactivate, and click Deactivate role (red light icon) > Continue.
    The role turns grey (offline) in the report pane.
  4. To reactivate the role, select the role, and click Activate role (green light icon).

About the Directory role

The Directory role identifies a Security Center system. It manages all entity configurations and system-wide settings.

How the Directory role works

Only a single instance of this role is permitted on your system. The server hosting the Directory role is called the main server, and must be set up first. All other servers you add in Security Center are called expansion servers, and must connect to the main server to be part of the same system.

The main functions of the Directory role are:

  • Client application connection authentication
  • Software license enforcement
  • Central configuration management
  • Event management and routing
  • Audit trail and activity trail management
  • Alarm management and routing
  • Incident management
  • Scheduled task execution
  • Macro execution

Directory role configuration

Because the Directory role is responsible for the authentication of all client connections, it cannot be configured in the Config Tool client application. To configure the Directory role, you must log on to Server Admin from a web browser.

Using Server Admin, you can perform the following administrative tasks:

  • Start/stop the Directory role
  • Manage the Directory database and change the data retention periods
  • View and modify your Security Center license
  • View and modify the main server’s password and communication ports
  • Convert the main server into an expansion server

In a multiple Directory server configuration, Directory failover and load balancing is managed by the Directory Manager role.

About Web-based SDK

The Web-based SDK role exposes the Security Center SDK methods and objects as web services to support cross-platform development.

It allows developers on platforms other than Windows (for example, Linux) to write custom programs that can interact with Security Center.

Have more questions? Submit a request