Access Users, Groups, and Credentials Guide

Overview

The Access Users, Groups, and Credentials API allows customers to retrieve and manage user capabilities, group memberships, and credentials.

It can be used for linking any third part user identity management system with Verkada.

API Endpoints

Users

Groups

Credentials

Using the Users, Groups, and Credentials API

Getting Started

Refer to the Quick Start Guide for instructions on generating a Verkada API key and making your first API requests.

Example Use Cases

Batch Sync

Some of our customers utilize the API in a batch process manner. At a sub real-time frequency, customers compare their total current user base in their third party system with the total Verkada Command Access Control User base. The differences between the two sets of users define the actions need to be taken in order to sync both systems.

  1. Users who exist in Verkada but not the customers User Information System will need to be either deleted from Verkada or deactivated.
  2. Users who do not exist in Verkada but exist in the customers User Information System will need to be added to Command.
  3. Any updated users, whether that be attributes like their name or employee ID, will need to be updated in Command.
  4. Any change in groups in the customer's User Information System may need to change the Access Control Access in Command. This is done by adding or removing users from Access Groups in command.

Real Time Update Sync

The other architecture our customers have used is a real-time sync. Changes made in the User Identity Management System are streamed out to a Message Queueing system where a consumer processes the changes and makes the relevant API calls to Command. The messages take the form of two schemas:

  1. The entire User data model from the User Information System.
    1. In this case, there is no indication of what change has occurred just that something has changed. A difference between that user object and its representation in Command will have to be done and actions taken accordingly.
  2. An action is specified and a payload is included.
    1. In this case, key action words have been specified (MODIFY, CREATE, DELETE, ACTIVATE, etc) and payloads for those action words have been defined. Each message will contain the action word that corresponds to the operation taken in the User Identity Managment System and its payload includes the relevant information needed to take that action in Command. The customers consumer script's job will be to map between the schema of the messages and the relevent API endpoints needed.