Provides basic login capabilities for portfolio users to access certian APIs.

POST v1/Login

Provides a simple login that returns a Json Web Token (JWT) in the content of the response. To use the JWT in subsequent requests it needs to be passed in the BMI_RDH cookie from the client. Using an uber user's credentials will return an unauthorized response.

GET v1/Logout

Logs the current user out by expiring the BMI_RDH cookie.


GET v1/Codes

Gets the utility defined codes used to label mobile reading field assignments. The tenant identifier is extracted from the token provided


POST v1/DeviceMessages

Sends messages into the BEACON backend. The messages go through an initial enrichment process that calcualtes flow and exception information. A single batch can include messages from more than one device.


Provides api for retrieving latest activations from ORION Cellular endpoints.

GET v1/Activation/{id}

Get the most recent activation for a sepcific ORION Cellular endpoint by serial number.

GET v1/Activation/List?serial_number={serial_number}&activation_date={activation_date}&customer_uuid={customer_uuid}

Retrieves a page of the ORION Cellular endpoint acvitaion list in descending order by activation date. To retrieve the next page the last scaned serial_number and activation_date must be provided. The next page is inclusive of the provided serial_number and activation_date.

GET v1/Activation/Export?startDate={startDate}&endDate={endDate}&customer_uuid={customer_uuid}

Exports the activation between the provided dates into a CSV file.


GET v1/DataSync

Get the status of the current sync information on the server.

POST v1/DataSync?version={version}

Synchronize a collector database from a device.

POST v2/DataSync

No documentation available.


POST v1/Authorization

Obselete API method will have to retain until all existing devices are updated to version 2. Begins the pairing process with BEACON. A unique serial number and the type of device communicating must be provided.

POST v2/Authorization

Begins the pairing process with BEACON to acquire an access key. The client can provide any number of key value pairs that will be reported back to the server. The following reserved keys are not allowed Id, Type, ValidThrough, AccessKey, and SecretKey.

GET v1/Authorization?accessKey={accessKey}

One time download of secret key from device. If given access key has not been issued or already issued a no conent HTTP status code is returned.