> For the complete documentation index, see [llms.txt](https://help.security.gallagher.com/knowledge-hub/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.security.gallagher.com/knowledge-hub/developer/rest-api/changelog.md). # Changelog #### 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. * 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. * POTENTIALLY BREAKING CHANGE: searching for cardholders using `pdf_xxx=""` or `pdf_xxx=` with no search value currently returns no cardholders. That is neither useful nor desired. Instead, a future version of Command Centre will return cardholders with a blank value for that PDF. * POTENTIALLY BREAKING CHANGE: the API route that lets you modify a cardholder by PATCH also works if you send it a POST. It should not, because POSTs create things, not modify them. The fix will break clients that rely on this. There should be no clients relying on it since the POST was not documented. * POTENTIALLY BREAKING CHANGE: in future, PATCH methods will return "200 Success" instead of "204 No Content" and may contain the object you modified plus a message from the API giving you feedback on your request. Please be aware that all 200-level response codes mean success, not just the ones old versions have been sending you. * You will be able to request the competencies that your operator has the permission to assign. That is determined by privileges, a competency setting, and an operator group setting. Current versions let you request the competencies that your operator has the permission to view, which is a larger set determined by privileges alone, and not suitable for interactive REST clients. * You will be able to create and delete alarm zones, and modify some basic fields. #### API changes in 9.70 * Potentially breaking change: searching for items using a totally-invalid type filter previously returned all items, as though the filter was absent. This was a bug. 9.70 returns no items in this case, and an explanation. * Potentially breaking change: a cardholder's value for a date PDF used to be in RFC 3339 or in the server's locale, depending on the route. Both included midnight. 9.70 returns them simply as 'YYYY-MM-DD', since date PDFs do not include a time. * Potentially breaking change: the API route that returns a cardholder's value of a string PDF as its payload used to send a zero-length body if the cardholder did not have a value for the PDF, but now returns a 404, as it does for missing PDFs of other types. #### API changes in 9.60-MR1 (a maintenance release) * Using this API to create a credential of a card type that has default validity times on it will transfer those times to the new credential, as it does when creating credentials through our thick clients. This is a bugfix. Previous versions left the new credential's `from` and `until` timestamps unset, if the client did not send them. #### API changes in 9.60 * You can move cardholders outside the system. * The items controller can give you items' descriptions and short names, if you ask. * The cardholder `allPdfs` field and "revealable" PDF types have been in the product for several versions and are now ready for prime time. * If you attempt to subscribe to status changes on items that are outside your operator's view, the 403 response now includes a copy of your list with the invalid items removed. #### 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. * The Apple Employee Badge Type and State Set now have proper canonical type names, improved from `type_279` and `type_280`. * Cardholders have accessibilities for skipping PIN entry and taking longer to get through a door, in addition to the existing accessibility to not use a scramble pad. #### API change in May 2026 maintenance releases * Potential breaking change in 9.20 MR7, 9.30 MR5, and 9.40 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. * POTENTIALLY BREAKING CHANGE: GovPass cards may have a new credentialClass and GovPass card states will have new names, depending on the card type and the site's licences. * You can create, modify, and delete access groups. #### 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! * POTENTIALLY BREAKING CHANGE: GovPass cards and card states may have changed item type names between 9.20 and 9.30, depending on the card type and the site's licences. * POTENTIALLY BREAKING CHANGE: for efficiency, 9.30 orders search results differently from 9.20 when your query does not include a `sort` parameter. If you care about the order of your items, tell the server how you want them sorted. #### API changes in 9.20 * You can filter events and items by their direct division. The older division search is recursive: it considers everything that has any of the filter's divisions anywhere in its ancestry. The new division search is shallow: it only returns events and items that are direct members of the division in the filter. #### API changes in 9.10 * You can request the name of an alarm's instruction, and the contents of the instruction itself. * You can request a locker's status and send an override to quarantine it. The use cases section shows how. #### API changes in 9.00 * A new event type `hasLocation` greatly simplifies the monitoring of cardholder movements. * A new `location` block on events greatly simplifies interpreting them. * You can search for cardholders by the access zone they are in. * GovPass cards have two new fields, `visitorContractor` and `ownedBySite`. #### Alarms and events API changes in 8.90 * BREAKING CHANGE: the operator must have the 'Create Events and Alarms' privilege in the division of the source item, if your request specifies a source item. Current versions only require that the operator has that privilege on at least one division. * To improve the symmetry between events and alarms, they both now carry a field `eventType` containing the ID and name of their type. The `type` field, which has different contents for alarms and events, is now obsolete (but still returned in results). * Alarms contain a new field called `event` containing a link to the corresponding event, mirroring the existing `alarm` field coming the other way from an event. * You can request a division's description. This has been possible since 8.50 but was not certified until 2022, so it gets a mention now. * Write-only access to card PINs. * You can set a reason when re-issuing or removing a card which will appear on the resulting event. The default is the card's previous state. * You can now set a visitor's state (signing in, etc.). Visits will return that, if you ask. * Bugfix: removing an operator group from a cardholder by PATCH was not possible in the early versions of 8.70 and 8.80. It was fixed in 8.70.2113, 8.80.1116, and all versions of 8.90. #### API changes in 8.80 * BREAKING CHANGE: Date PDFs no longer come out of the API with a time component or time zone designator, because date PDFs don't hold a time or time zone. Previously they came out as midnight UTC, which implied more accuracy than date PDFs hold. * Redactions. * An optional PDF field `operatorAccess` contains the level of access your operator has to cardholders' values for the PDF. * Card type `regex` and `regexDescription` fields. * Email and mobile PDFs return their 'Default Notifications' flag on request. This actually happened in 8.50 but did not make it into the "changes" list. * Early-adopter support for Interlock groups. #### API changes in 8.70 * Each event in a page of search results will contain URLs to continue the search after that event. This is a significant benefit to integrations that extract large pages of events and may encounter a problem mid-page, and have to resume without loss or duplication later. * A new privilege 'View Cardholder Events' grants visibility of an event if the operator has the privilege in both the event's division and the event's cardholder's division. This allows a site to create a REST client that can monitor selected cardholders' movements through selected areas, but cannot see any other activity in those areas. * You may now use the `relatedItem` query parameter in an item search to find events that are associated with a particular item. * BREAKING CHANGE: Missing image PDFs will no longer have "not captured" as their value. Instead, they will have no value at all. * A cardholder's operator group memberships (added in 8.50) now contain an href that you can use in an HTTP DELETE as another way of removing a cardholder from an operator group. * The server returns 1000 items by default instead of 100. * Image PDFs tell you whether they are the cardholder's profile picture. * Image PDFs have a new optional field `contentType` that returns their MIME type. This deprecates the old `imageFormat` field, which is non-standard. * Asking for a particular PDF on a cardholder (by putting `pdf_XXX` into the `fields` query parameter) will cause it to appear even if the cardholder has no value for that PDF. Previous versions only showed it if it had a non-blank value. * Attempting to give a cardholder a competency they already have will fail instead of allowing it and raising an alarm. Note that a cardholder having two links to the same competency leads to undefined behaviour. * A new query parameter `requested_by` lets you attribute overrides to another cardholder. Your operator must have the 'Delegate API Activity' privilege in the cardholder's division. * Item updates now include fields that changed to an empty value. Versions up to 8.60 returned an update but did not tell you which field changed or what it changed to, if it changed to a blank. #### API changes in 8.60 * Card numbers on Bluetooth (mobile) and PIV card events are now full-length. Mobile numbers are now the phone's ID string, changed from the number that 8.50 returned. Decimal numbers now come out unsigned. Note that neither 8.50's numbers nor 8.60's ID strings are guaranteed unique across phones. * Access events that do not have a card, such as someone entering their user code instead of badging their card, will no longer return a card block. * You can search for cardholders by division or description. * 8.60 rejects unsupported HTTP verbs instead of treating them like a GET. For example, if you send a POST to `/api/competencies` 8.50 will return a list of competencies but 8.60 will return a 400-level error. * In build 8.60.1684 or later, attempting to give a cardholder a competency they already have will fail instead of allowing it and raising an alarm. Note that a cardholder having two links to the same competency leads to undefined behaviour. * The RESTOverrides licence allows you to find items and their override URLs. #### API changes in 8.50 * The server property that turns off client certificate checking changed. * Divisions can return some of their Visitor Management configuration. * You can view any item's notes. You have been able to for a while now, but it was missing from this document. * You can request a division's description. * You can manage operators by setting their operator group memberships and logon credentials. * You can view operator groups. * Lockers and locker banks report the hardware controller where they reside. * Cardholders report their 'disable cipher pad' setting (vision impairment). * Card types will show their division on request. * Cardholders can have default floors and passenger type flags per elevator group. Thyssen-Krupp systems can prepare an elevator car when Command Centre grants a cardholder access through lobby turnstiles. * You can list receptions and see enough of a division's visitor management configuration to create and manage visits. * Image Personal Data Field definitions will show their width, height, and format (JPG, PNG, or BMP) on request. * Email and mobile PDFs return their 'Default Notifications' flag on request. * A schedules API provides CRUD of the six schedule item types. * A day categories API returns the day categories you need for those schedules. * A pulse overrides an output. * A 'connectedController' field grew on the item types that did not already have it. * An elevator groups API provides a view of elevator groups so that you can set a cardholder's default floor. #### API changes in 8.40 * You may now use the `fields` query parameter to tailor the fields that come back for events and alarms. * Operator add, modify, and delete events now contain a link to the affected item in a new `modifiedItem` block, deprecating the `accessGroup` block for those event types. * All operator events now contain the operator's name at the time. * All events now contain the name of the event's division. * The item search can now filter multiple item types. * Events now show their origin when they have arrived from a remote server (in a multiserver environment). * Access groups have 22 new fields showing the privileges and access they grant their members. These new fields are in the default set for the detail view. * Access groups now return the alarm zones over which they have privilege. * Items on remote servers now show their origin server in a new `serverDisplayName` field. * Cards contain the date and time of their last print or encode, and their issue level at the time. #### API changes in 8.30 * The items API has methods that let you monitor the status of large numbers of items. * Doors related to guard tour events now appear in an event's `door` block. * Cardholder change tracking lets you synchronise users into an external system by informing it of changes as they occur. * Cardholder group membership hrefs now contain a long string where they used to contain a small integer. Integrations that cache membership hrefs a) should not and b) will need to refresh. * A cardholder's card object now contains a Boolean field called `trace` indicating whether its trace flag is set. A card with tracing on generates an event every time it is used. * A 'connectedController' field in the door detail returns the ID and name of the door's hardware controller (a hardware controller, not an API controller). #### API changes in 8.20 * Alarms and events with a related cardholder now show the cardholder's current first and last name in separate fields. * The `name` field on an alarm or event with a related cardholder is now the cardholder's name at the time of the event, rather than at the time of the request. * You can use the 'fields' parameter to add the 'details' field to an event summary. * A new field `update_location` on a cardholder gives a link to a POST that changes his or her current location (access zone). * An update\_cardholder\_location call on the Access Zones API returns you the list of Access Zones into which your operator is allowed to move cardholders. * Lockers and locker banks are now visible with the RESTStatus licence, including whether a locker is available or allocated. You still need RESTCardholders to see which cardholder/s a locker is assigned to. * Lockers moved from the locker banks controller into their own. That changed their hrefs. * Bugfix: you can now change a cardholder's division. * A cardholder's relationships block now contains the role holder's two name fields. The `name` field, present since 7.90, is simply these two fields joined with a space, and is therefore ambiguous when a cardholder only has one name. #### API changes in 8.10.1112 * You can send an override to a locker to open it. * You can use the `fields` query parameter to select the fields you receive from locker bank summary and details GETs. The use cases section shows how. #### API changes in 8.10 * Incoming events * Events now show their related access groups and doors for external event types. * There is a card types API that returns the card types your operator is able to use when assigning cards to cardholders. * There is a PDF API that returns the personal data field definitions your operator is able to see. * You can change the notifications flag on a cardholder's PDF. * Certificates and biometric data are available on PIV cards. * An inputs API gives you the state of 'input' hardware items and lets you override them. It is very similar to the outputs API. * PIV certificates and biometrics are now available without a customisation. They are too large to send to all REST clients so you must ask for them using the `fields` parameter. ## Dummy path. > This path does not exist in the API. It is in the documentation to satisfy HTML\ > renderers like Gitbook, Sourcey, and Zudoku that require at least one path in every tag.
```json {"openapi":"3.2.0","info":{"title":"Command Centre REST API","version":"2.0"},"tags":[{"name":"Changelog","description":"\n### API changes on the roadmap\n\n* Alarms will have a block containing their event group, as events do.\n\n* You will be able to set the number of alarms you want coming back from a GET, as you can with\n events.\n\n* Events indicating that an operator modified an item may not have a cardholder at the end of\n the `operator` href. It may be a new kind of item, because we have new events coming that\n will indicate when an integration modifies an item rather than a human operator.\n\n* POTENTIALLY BREAKING CHANGE: searching for cardholders using `pdf_xxx=\"\"` or `pdf_xxx=` with\n no search value currently returns no cardholders. That is neither useful nor desired.\n Instead, a future version of Command Centre will return cardholders with a blank value for\n that PDF.\n\n* POTENTIALLY BREAKING CHANGE: the API route that lets you modify a cardholder by PATCH also\n works if you send it a POST. It should not, because POSTs create things, not modify them.\n The fix will break clients that rely on this. There should be no clients relying on it since\n the POST was not documented.\n\n* POTENTIALLY BREAKING CHANGE: in future, PATCH methods will return \"200 Success\" instead of\n \"204 No Content\" and may contain the object you modified plus a message from the API giving\n you feedback on your request. Please be aware that all 200-level response codes mean success,\n not just the ones old versions have been sending you.\n\n* You will be able to request the competencies that your operator has the permission to assign.\n That is determined by privileges, a competency setting, and an operator group setting.\n Current versions let you request the competencies that your operator has the permission to\n view, which is a larger set determined by privileges alone, and not suitable for interactive\n REST clients.\n\n* You will be able to create and delete alarm zones, and modify some basic fields.\n\n### API changes in 9.70\n\n* Potentially breaking change: searching for items using a totally-invalid type filter\n previously returned all items, as though the filter was absent. This was a bug. 9.70 returns\n no items in this case, and an explanation.\n\n* Potentially breaking change: a cardholder's value for a date PDF used to be in RFC 3339 or in\n the server's locale, depending on the route. Both included midnight. 9.70 returns them\n simply as 'YYYY-MM-DD', since date PDFs do not include a time.\n\n* Potentially breaking change: the API route that returns a cardholder's value of a string PDF\n as its payload used to send a zero-length body if the cardholder did not have a value for the\n PDF, but now returns a 404, as it does for missing PDFs of other types.\n\n### API changes in 9.60-MR1 (a maintenance release)\n\n* Using this API to create a credential of a card type that has default validity times on it\n will transfer those times to the new credential, as it does when creating credentials through\n our thick clients. This is a bugfix. Previous versions left the new credential's `from` and\n `until` timestamps unset, if the client did not send them.\n\n### API changes in 9.60\n\n* You can move cardholders outside the system.\n\n* The [items controller](items) can give you items' descriptions and short names, if you\n ask.\n\n* The cardholder `allPdfs` field and \"revealable\" PDF types have been in the product for several\n versions and are now ready for prime time.\n\n* If you attempt to subscribe to status changes on items that are outside your operator's\n view, the 403 response now includes a copy of your list with the invalid items removed.\n\n### API changes in 9.50\n\n* OIDC login support for operators.\n\n* Creating an [item status subscription](items#post-api-items-updates) and [collecting the\n first batch of changes](items#get-api-items-updates) will no longer return the first set of\n results twice. If your application follows the algorithm at the second link above it will\n always be compatible with this API.\n\n The performance improvements were such that we felt it worthwhile to port it back to all\n supported versions, so it is also present in the latest maintenance releases of 9.10 through\n 9.40.\n\n* Potential breaking change: the maximum length of an item's name increased from 60 to 110\n characters, and attempts to set a name longer than that will fail. Earlier versions silently\n truncated the name and let the update proceed. Cardholder first and last names remain capped\n at 50 characters each.\n\n* The Apple Employee Badge Type and State Set now have proper canonical type names, improved\n from `type_279` and `type_280`.\n\n* Cardholders have accessibilities for skipping PIN entry and taking longer to get through a\n door, in addition to the existing accessibility to not use a scramble pad.\n\n### API change in May 2026 maintenance releases\n\n* Potential breaking change in 9.20 MR7, 9.30 MR5, and 9.40 MR2: attempts to set the name of an\n item that is not a cardholder to a string that is longer than 60 characters will fail.\n Earlier versions silently truncated the name and let the update proceed. There is no change\n to the handling of cardholders' names.\n\n### API changes in 9.40\n\n* Support for half-cycle door locks. Common in correctional facilities, half-cycle locks remain\n unlocked until closed. Regular doors unlock for a few seconds before locking again.\n\n* POTENTIALLY BREAKING CHANGE: GovPass cards may have a new credentialClass and GovPass card\n states will have new names, depending on the card type and the site's licences.\n\n* You can create, modify, and delete [access groups](access-groups).\n\n### API changes in 9.30\n\n* You can create, modify, and delete divisions and access groups.\n\n* The server will accept TLS 1.3 connections when running on suitable versions of Windows.\n Prior versions would only accept TLS 1.2 connections.\n\n* An API client can switch its own status between `normal` and `faulty`, and can set arbitrary\n status text. Marking the item as faulty will raise an alarm in Command Centre.\n\n* Command Centre can, optionally, raise an alarm if an API client has not made an API call\n within a configurable period. This is an addition to Command Centre, not to the API, but\n deserves a mention here for developers considering adding status monitoring to their\n integrations. It may be done for you!\n\n* POTENTIALLY BREAKING CHANGE: GovPass cards and card states may have changed item type names\n between 9.20 and 9.30, depending on the card type and the site's licences.\n\n* POTENTIALLY BREAKING CHANGE: for efficiency, 9.30 orders search results differently from 9.20\n when your query does not include a `sort` parameter. If you care about the order of your\n items, tell the server how you want them sorted.\n\n### API changes in 9.20\n\n* You can filter events and items by their direct division. The older division search is\n recursive: it considers everything that has any of the filter's divisions anywhere in its\n ancestry. The new division search is shallow: it only returns events and items that are\n direct members of the division in the filter.\n\n### API changes in 9.10\n\n* You can request the name of an alarm's instruction, and the contents of the instruction itself.\n\n* You can request a locker's status and send an override to quarantine it. The [use\n cases](lockers#use-cases) section shows how.\n\n### API changes in 9.00\n\n* A new event type `hasLocation` greatly simplifies the [monitoring of cardholder\n movements](events#get-api-events).\n \n* A new [`location` block on events](events#location-events-in-9.00) greatly\n simplifies interpreting them.\n\n* You can search for cardholders by the access zone they are in.\n\n* GovPass cards have two new fields, `visitorContractor` and `ownedBySite`.\n\n### Alarms and events API changes in 8.90\n\n* BREAKING CHANGE: the operator must have the 'Create Events and\n Alarms' privilege in the division of the source item, if your request specifies a source item.\n Current versions only require that the operator has that privilege on at least one division.\n\n* To improve the symmetry between events and alarms, they both now carry a field `eventType`\n containing the ID and name of their type. The `type` field, which has different\n contents for alarms and events, is now obsolete (but still returned in results).\n\n* Alarms contain a new field called `event` containing a link to the corresponding event,\n mirroring the existing `alarm` field coming the other way from an event.\n\n* You can request a division's description. This has been possible since 8.50 but was not\n certified until 2022, so it gets a mention now.\n\n* Write-only access to card PINs.\n\n* You can set a reason when re-issuing or removing a card which will appear on the\n resulting event. The default is the card's previous state.\n\n* You can now [set](visits#patch-api-visits-id-visitors-visitorId-) a visitor's state\n (signing in, etc.). Visits will return that, if you ask.\n\n* Bugfix: removing an operator group from a cardholder by PATCH was not possible in the early\n versions of 8.70 and 8.80. It was fixed in 8.70.2113, 8.80.1116, and all versions of 8.90.\n\n### API changes in 8.80\n\n* BREAKING CHANGE: Date PDFs no longer come out of the API with a time component or time zone\n designator, because date PDFs don't hold a time or time zone. Previously they came out as\n midnight UTC, which implied more accuracy than date PDFs hold.\n\n* [Redactions](redactions).\n\n* An optional PDF field `operatorAccess` contains the level of access your operator has to\n cardholders' values for the PDF.\n\n* Card type `regex` and `regexDescription` fields.\n\n* Email and mobile PDFs return their 'Default Notifications' flag on request. This actually\n happened in 8.50 but did not make it into the \"changes\" list.\n\n* Early-adopter support for [Interlock groups](interlock-groups).\n\n### API changes in 8.70\n\n* Each event in a page of search results will contain URLs to continue the search after that\n event. This is a significant benefit to integrations that extract large pages of events and\n may encounter a problem mid-page, and have to resume without loss or duplication later.\n\n* A new privilege 'View Cardholder Events' grants visibility of an event if the operator has the\n privilege in both the event's division and the event's cardholder's division. This allows a\n site to create a REST client that can monitor selected cardholders' movements through selected\n areas, but cannot see any other activity in those areas.\n\n* You may now use the `relatedItem` query parameter in an item search to find events that are\n associated with a particular item.\n\n* BREAKING CHANGE: Missing image PDFs will no longer have \"not captured\" as their value.\n Instead, they will have no value at all.\n\n* A cardholder's operator group memberships (added in 8.50) now contain an href that you can use\n in an HTTP DELETE as another way of removing a cardholder from an operator group.\n\n* The server returns 1000 items by default instead of 100.\n\n* Image PDFs tell you whether they are the cardholder's profile picture.\n\n* Image PDFs have a new optional field `contentType` that returns their MIME type. This\n deprecates the old `imageFormat` field, which is non-standard.\n\n* Asking for a particular PDF on a cardholder (by putting `pdf_XXX` into the `fields` query parameter) will\n cause it to appear even if the cardholder has no value for that PDF. Previous versions only\n showed it if it had a non-blank value.\n\n* Attempting to give a cardholder a competency they already have will fail instead of allowing\n it and raising an alarm. Note that a cardholder having two links to the same competency leads\n to undefined behaviour.\n\n* A new query parameter `requested_by` lets you attribute overrides to another cardholder. Your\n operator must have the 'Delegate API Activity' privilege in the cardholder's division.\n\n* Item updates now include fields that changed to an empty value. Versions up to 8.60 returned\n an update but did not tell you which field changed or what it changed to, if it changed to a\n blank.\n\n### API changes in 8.60\n\n* Card numbers on Bluetooth (mobile) and PIV card events are now full-length. Mobile numbers\n are now the phone's ID string, changed from the number that 8.50 returned. Decimal numbers\n now come out unsigned. Note that neither 8.50's numbers nor 8.60's ID strings are guaranteed\n unique across phones.\n\n* Access events that do not have a card, such as someone entering their user code instead of\n badging their card, will no longer return a card block.\n\n* You can search for cardholders by division or description.\n\n* 8.60 rejects unsupported HTTP verbs instead of treating them like a GET. For example, if you\n send a POST to `/api/competencies` 8.50 will return a list of competencies but 8.60 will\n return a 400-level error.\n\n* In build 8.60.1684 or later, attempting to give a cardholder a competency they already have\n will fail instead of allowing it and raising an alarm. Note that a cardholder having two\n links to the same competency leads to undefined behaviour.\n\n* The RESTOverrides licence allows you to find items and their override URLs.\n\n### API changes in 8.50\n\n* The server property that turns off [client certificate checking](api-authentication) changed.\n\n* Divisions can return some of their Visitor Management configuration.\n\n* You can view any item's notes. You have been able to for a while now, but it was missing from\n this document.\n\n* You can request a division's description.\n\n* You can manage operators by setting their operator group memberships and logon credentials.\n* You can view [operator groups](operator-groups).\n* Lockers and locker banks report the hardware controller where they reside.\n* Cardholders report their 'disable cipher pad' setting (vision impairment).\n* Card types will show their division on request.\n\n* Cardholders can have default floors and passenger type flags per elevator group.\n Thyssen-Krupp systems can prepare an elevator car when Command Centre grants a cardholder\n access through lobby turnstiles.\n\n* You can list receptions and see enough of a division's visitor management configuration to\n create and manage visits.\n\n* Image Personal Data Field definitions will show their width, height, and format (JPG, PNG, or\n BMP) on request.\n\n* Email and mobile PDFs return their 'Default Notifications' flag on request.\n\n* A [schedules API](schedules) provides CRUD of the six schedule item types.\n\n* A [day categories API](day-categories) returns the day categories you need for those\n schedules.\n\n* A [pulse](outputs#post-api-outputs-id-pulse) overrides an output.\n\n* A 'connectedController' field grew on the item types that did not already have it.\n\n* An [elevator groups API](elevator-groups) provides a view of elevator groups so that you\n can [set a cardholder's default\n floor](cardholders#patch-api-cardholders-id-patch).\n\n### API changes in 8.40\n\n* You may now use the `fields` query parameter to tailor the fields that come back for events\n and alarms.\n\n* Operator add, modify, and delete [events](models#eventsummary) now contain a link to the\n affected item in a new `modifiedItem` block, deprecating the `accessGroup` block for those\n event types.\n\n* All operator events now contain the operator's name at the time.\n\n* All events now contain the name of the event's division.\n\n* The [item search](#path/Items/get/api/items) can now filter multiple item types.\n\n* Events now show their origin when they have arrived from a remote server (in a multiserver\n environment).\n\n* Access groups have 22 new fields showing the privileges and access they grant their members.\n These new fields are in the default set for the [detail view](models#accessgroupdetail).\n\n* Access groups now return the alarm zones over which they have privilege.\n\n* Items on remote servers now show their origin server in a new `serverDisplayName` field.\n\n* Cards contain the date and time of their last print or encode, and their issue level at the\n time.\n\n### API changes in 8.30\n\n* The [items API](items) has methods that let you monitor the status of large numbers of\n items.\n\n* Doors related to guard tour events now appear in an event's `door` block.\n\n* Cardholder [change tracking](cardholder-change-tracking) lets you synchronise users into an\n external system by informing it of changes as they occur.\n\n* Cardholder group membership hrefs now contain a long string where they used to contain a small\n integer. Integrations that cache membership hrefs a) should not and b) will need to refresh.\n\n* A cardholder's card object now contains a Boolean field called `trace` indicating whether its\n trace flag is set. A card with tracing on generates an event every time it is used.\n\n* A 'connectedController' field in the [door detail](models#doordetail) returns the ID and\n name of the door's hardware controller (a hardware controller, not an API controller).\n\n### API changes in 8.20\n\n* Alarms and events with a related cardholder now show the cardholder's current first and last\n name in separate fields.\n\n* The `name` field on an alarm or event with a related cardholder is now the cardholder's name\n at the time of the event, rather than at the time of the request.\n\n* You can use the 'fields' parameter to add the 'details' field to an event summary.\n\n* A new field `update_location` on a cardholder gives a link to a\n [POST](cardholders#post-cardholders-id-update_location) that changes his or her\n current location (access zone).\n\n* An\n [update_cardholder_location](access-zones#get-api-access_zones-update_cardholder_location)\n call on the Access Zones API returns you the list of Access Zones into which your operator is\n allowed to move cardholders.\n\n* Lockers and locker banks are now visible with the RESTStatus licence, including whether a\n locker is available or allocated. You still need RESTCardholders to see which cardholder/s a\n locker is assigned to.\n\n* Lockers moved from the locker banks controller into their own. That changed their hrefs.\n\n* Bugfix: you can now change a cardholder's division.\n\n* A cardholder's [relationships block](models#cardholderrelationship) now contains the\n role holder's two name fields. The `name` field, present since 7.90, is simply these two\n fields joined with a space, and is therefore ambiguous when a cardholder only has one name.\n\n### API changes in 8.10.1112\n\n* You can send an [override](lockers#post-api-id-open) to a locker to open it.\n\n* You can use the `fields` query parameter to select the fields you receive from locker bank\n [summary](lockers#get-api-locker_banks) and\n [details](lockers#get-api-locker_banks-id-) GETs. The [use\n cases](lockers#use-cases) section shows how.\n\n### API changes in 8.10\n\n* [Incoming events](events#post-api)\n\n* Events now show their related [access groups and doors](models#eventsummary) for\n external event types.\n\n* There is a [card types API](card-types#get-api-card_types-assign) that returns the card types\n your operator is able to use when assigning cards to cardholders.\n\n* There is a [PDF API](pdf-definitions#get-api-personal_data_fields) that returns the\n personal data field definitions your operator is able to see.\n\n* You can change the notifications flag on a cardholder's PDF.\n\n* Certificates and biometric data are available on PIV cards.\n\n* An [inputs API](inputs) gives you the state of 'input' hardware items and lets you\n override them. It is very similar to the outputs API.\n\n* PIV certificates and biometrics are now available without a customisation. They are too large\n to send to all REST clients so you must ask for them using the `fields` parameter.\n"}],"servers":[{"url":"https://127.0.0.1:8904"}],"security":[{"API_key":[]},{"basic":[]}],"components":{"securitySchemes":{"API_key":{"type":"apiKey","name":"Authorization","in":"header","description":"\nClients authenticate by including a pre-shared API key in the `Authorization` header of each\nrequest after an authorisation method of `GGL-API-KEY`:\n\n`Authorization: GGL-API-KEY C774-B01F-D695-AA4B-215F-A158-AC22-ADEB`\n\nFor a fuller description see [API authentication](api-authentication).\n"},"basic":{"type":"http","scheme":"basic","description":"This is HTTP Basic authentication using a blank username and the API key as the password.\n\nExample: `Authorization: Basic OkM3NzQtQjAxRi1ENjk1LUFBNEItMjE1Ri1BMTU4LUFDMjItQURFQg==`\n\nThat example is equivalent to the example in the description of the api_Key method:\nprepending a colon to the API key beginning with `C774` then encoding it into Base64\nproduces the 56 characters beginning with `OkM3`.\n\nThe colon is a separator between a username, which is blank in our case, and the password,\nwhich is our API key.\n\nFor a fuller description see [API authentication](api-authentication)\n"}}},"paths":{"/api/changelog":{"delete":{"tags":["Changelog"],"summary":"Dummy path.","description":"This path does not exist in the API. It is in the documentation to satisfy HTML\nrenderers like Gitbook, Sourcey, and Zudoku that require at least one path in every tag.\n","responses":{"200":{"description":"This result is unlikely."},"404":{"description":"This path does not exist."}}}}}} ``` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://help.security.gallagher.com/knowledge-hub/developer/rest-api/changelog.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.