The Command Center API is a RESTful Internet protocol built around making semantically meaningful HTTPS requests to access or modify a resource (usually done by an employee). The API can be used to manipulate employee data and to generate reports in several formats.
Command Center is infinitely customizable. Add as many custom tables and fields as you like.
The Tables API allows you to grab tabular data for the various tables in Command Center.
Command Center has a standard API-based mechanism for retrieving the photo binary data.
The Last Changed API allows you to discover which records have recently been added, changed or deleted.
Webhooks allow you to monitor changes made in the Command Center system.
The Policies API allows you to manipulate policies, policyholders, insured assets and coverage information as well as insured assed dependant data.
The Create Invoices API is used to send approved monthly policy invoices to Command Center, so that the policyholder can see and pay them from their smartphone.
The Command Center supports several field types while requiring as few API lookup calls as possible.
There are three primary entities when dealing with telemetry, raw, qualified, and scored. All are available in real time via message queues, making them available to 3rd party data lakes for analysis.
The Metadata API allows you to get data about data so you can learn what is being used and what values the account supports.
The Login API is an alternative method to get an API key that identifies a particular user.
While our RESTful interface requires very little in the way of application bindings, Command Center bindings are open sourced.
The First Notice of Loss and Claims API allow you to send raw claims information for a policy to Command Center, including type, status and historical details. We take this data and make it available in a dynamic manner to mobile users.
Each API request sent from a third-party application to the Command Center website will be authenticated and permissioned as if a real user were using the software. The group permissions of the user associated with the API request will determine which fields and employees each API request is allowed to view and/or edit.
To use the API, each user should have one or more secret API keys that identify that user to the API. The API secret key is a 160-bit number expressed in hexadecimal form. This is an astronomically large number of unique keys, which means that guessing an API key is nearly impossible.
To generate an API key for a given user, users should log in and click their name in the upper right hand corner of any page to get to the user context menu. There will be an "API Keys" option in that menu to go to the page.
If an unknown API key is used repeatedly, the API will disable access for a period of time. Users will still be able to log in to the Command Center website during this time. When the API is disabled, it will send back an HTTP 403 Forbidden response to any requests it receives.
At the HTTP level, the API key is sent over HTTP Basic Authentication. Use the secret key as the username and any random string for the password.
For more information about HTTP Basic Authentication, see this helpful wikipedia article.
Every request includes an HTTP status code with the result. The status code should be examined before the response.
There are two main entities that you will be concerned about when interacting with Command Center: System users and Passport users.
Passport users are the core data object in Command Center. Each Passport user is identified by an immutable unique ID. This entity is where information such as creation dates, personal information, SMS, addresses and contacts are stored.
System Users are the people who have been authorized to access Command Center in some capacity. A System User is also necessarily a Passport User.
PassPort Users are identified by an immutable unique user ID. Each user can also have one or more unique API keys. Individual API keys belonging to a user can be revoked while leaving the other keys active.
Every attempt will be made to make only forward compatible changes to the API. To assist this effort, API consumers should ignore any XML tags and attributes they do not recognize.
The API will support multiple major version numbers of the API. Currently the only version is "v1". If a major API change becomes necessary, we’ll create a new major version number and communicate the change to our partners. We’ll maintain the existing "v1" API for a reasonable period of time.