Command Centre REST API API Reference

Welcome to the developer documentation for the Command Centre REST interface.

The files linked from here show you how you can manage Command Centre using HTTP requests. Each file contains an introduction to its particular area of the API, instructions on authenticating to the server, and tips on how to accomplish common tasks, as well as the usual reference information for paths and data.

They do not show how to set up the Command Centre server to answer your REST calls. To do that, search the Configuration Client's online help for 'REST'.

You could also look at the sample code shipped with Command Centre, on the install media alongside this documentation in the 'Utilities/REST API' folder. There are several Visual Studio projects that compile into .NET applications you could observe making HTTP requests against your own server (in a development environment, of course).

Version: 1.0.0

Documentation suite

Microsoft Edge users please note: early versions did not render the table of contents correctly in the orange column on the left, making navigation difficult. Chrome, Firefox, and recent versions of Edge work well.

The API's reference documentation divides into:

Alarms, events, bulk status monitoring, and generic items

The alarms and events APIs let you download, monitor, and create events, and download, monitor, and manage alarms.

This section also covers API calls that support divisions and items as they relate to events, as well as bulk status monitoring. It does not cover the deep configuration of items: see Status and Overrides.
Cardholders and related items The cardholder parts of the API let you manage your users, their personal data and credentials (cards), and their links to associated items such as access groups, roles, operator groups, competencies, and lockers.
Status, overrides, and configuration of non-cardholder items

These functions let you monitor and override the types of Command Centre items that have their own status and typically appear on site plans, including access zones, alarm zones, doors, fence zones, inputs, outputs, macros, elevator groups, interlock groups, and schedules.

Despite its name this section does not cover mass-monitoring item status.

PIV cards This supplement describes how to work with PIV and PIV-I cards. It is separate from the main cardholder documentation in the interest of brevity.

API changes on the roadmap

  • Alarms will have a block containing their event group, as events do.

  • You will be able to set the number of alarms you want coming back from a GET, as you can with events.

  • Potentially breaking change: the API routes that return the value of a cardholder's date PDF present it in either in RFC 3339 format with a time, or a format specific to the server's locale, depending on the route. A future version will change to date-only ISO 8601 (date PDFs only contain a date, not a time).

  • Potentially breaking change: the API route that returns the value of a string PDF will change to return a 404 if the cardholder does not have a value for it, as it does for image and date PDFs. Currently, missing string PDFs come out as a zero-length payload.

  • Events indicating that an operator modified an item may not have a cardholder at the end of the operator href. It may be a new kind of item, because we have new events coming that will indicate when an integration modifies an item rather than a human operator.

API changes in 9.50

  • OIDC login support for operators.

  • Creating an item status subscription and collecting the first batch of changes will no longer return the first set of results twice. If your application follows the algorithm at the second link above it will always be compatible with this API.

    The performance improvements were such that we felt it worthwhile to port it back to all supported versions, so it is also present in the latest maintenance releases of 9.10 through 9.40.

  • Potential breaking change: the maximum length of an item's name increased from 60 to 110 characters, and attempts to set a name longer than that will fail. Earlier versions silently truncated the name and let the update proceed. Cardholder first and last names remain capped at 50 characters each.

API change in May 2026 maintenance releases

  • Potential breaking change in 9.20.4290 MR7, 9.30.3891 MR5, and 9.40.2492 MR2: attempts to set the name of an item that is not a cardholder to a string that is longer than 60 characters will fail. Earlier versions silently truncated the name and let the update proceed. There is no change to the handling of cardholders' names.

API changes in 9.40

  • Support for half-cycle door locks. Common in correctional facilities, half-cycle locks remain unlocked until closed. Regular doors unlock for a few seconds before locking again.

API changes in 9.30

  • You can create, modify, and delete divisions and access groups.

  • The server will accept TLS 1.3 connections when running on suitable versions of Windows. Prior versions would only accept TLS 1.2 connections.

  • An API client can switch its own status between normal and faulty, and can set arbitrary status text. Marking the item as faulty will raise an alarm in Command Centre.

  • Command Centre can, optionally, raise an alarm if an API client has not made an API call within a configurable period. This is an addition to Command Centre, not to the API, but deserves a mention here for developers considering adding status monitoring to their integrations. It may be done for you!

Paths

Documentation by Spectacle