API Documentation
API Documents
HomeHelp CenterCommand

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

User Photo Syncing

The access user information endpoints can be used to sync profile photos between another application and Verkada. Here's how you can use these endpoints to create a solution for syncing profile photos:

Syncing Photos from Another Application to Verkada

  1. Retrieve Verkada Access Users' Information:
    1. Use the Get All Access Users endpoint to fetch a list of all your Verkada users.
    2. Compare the profile_photo_last_updated timestamp in each user object with the timestamp the photo was last modified in the third-party system to determine if a user's profile photo requires updating.
  2. Update Outdated or Missing Photos:
    1. For users with outdated or missing profile photos, call the Upload Profile Photo endpoint to upload or update their profile photos.
    2. If a user's profile photo has been removed in the third-party system, use the Delete Profile Photo endpoint to remove their photo in Verkada.

Syncing Photos from Verkada to Another Application

  1. To sync photos from Verkada to another application, follow a similar process as outlined above by comparing photo update timestamps between the systems.
  2. Use the Get Profile Photo endpoint to retrieve the required user photos from Verkada.
  3. Update the user’s profile photo in the third-party application with the data retrieved from Verkada.

Batch User 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 User 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.