Easy to Access, Easy to Modify

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.


Key Features 

Artboard 2

Single Dimensional Data

Command Center is infinitely customizable. Add as many custom tables and fields as you like.


Artboard 4

Tabular Data

The Tables API allows you to grab tabular data for the various tables in Command Center.


Artboard 6


Command Center has a standard API-based mechanism for retrieving the photo binary data.


Artboard 8

Last Change Information

The Last Changed API allows you to discover which records have recently been added, changed or deleted.


Artboard 9


Webhooks allow you to monitor changes made in the Command Center system.


Blue_business_information_icon blue


The Policies API allows you to manipulate policies, policyholders, insured assets and coverage information as well as insured assed dependant data.


billing and payment (1)

Create Invoices

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.


Artboard 3

Field Types

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.


Artboard 7


The Metadata API allows you to get data about data so you can learn what is being used and what values the account supports.


Artboard 1


The Login API is an alternative method to get an API key that identifies a particular user.


Artboard 10

Language Bindings

While our RESTful interface requires very little in the way of application bindings, Command Center bindings are open sourced.


Vehicle diagnostics

FNOL / Claims

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.


Making Requests

  • All requests made to our APIs must be sent over HTTPS. The SSL certificate used for the HTTPS connection is signed and all implementations should configure their SSL layer to verify it.
  • requests are made to a URL that begins with: https://api.baseline.info/
  • API requests can be throttled if Baseline deems them to be too frequent. Implementations should always be ready for a 503 Service Unavailable response.
  • Implementations should also always be ready for general Internet packet loss resulting in broken connections with no HTTP response.
  • Each employee has an immutable employee ID that is unique within a single company that you can use to reference the employee.
  • All requests should be in UTF-8.

HTTP Status Codes

Every request includes an HTTP status code with the result. The status code should be examined before the response.

Successful status codes (2xx)
  • 200 OK - The request was successful.
  • 201 Created - The resource was successfully created. Confirms a success when creating a new employee, time off request, etc.
Client error status codes (4xx)
  • 400 Bad Request - The request was invalid or could not be understood by the server. Resubmitting the request will likely result in the same error.
  • 401 Unauthorized - Your API key is missing.
  • 403 Forbidden - The application is attempting to perform an action it does not have privileges to access. Verify your API key belongs to an enabled user with the required permissions.
  • 404 Not Found - The resource was not found with the given identifier. Either the URL given is not a valid API, or the ID of the object specified in the request is invalid.
  • 406 Not Acceptable - The request contains references to non-existent fields.
  • 409 Conflict - The request attempts to create a duplicate. For employees, duplicate emails are not allowed. For lists, duplicate values are not allowed.
  • 429 Limit Exceeded - The account has reached its employee limit. No additional employees could be added.
Server error status codes (5xx)
  • 500 Internal Server Error - The server encountered an error while processing your request and failed.
  • 502 Gateway Error - The load balancer or web server had trouble connecting to the Command Center app. Please try the request again.
  • 503 Service Unavailable - The service is temporarily unavailable. Please try the request again.
You can future proof your code by using the following ranges:
  • 200–299 as success
  • 400–499 as client request errors
  • 500–599 as server errors

System Users & Passport Users

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.


Compatibility Between Versions

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.