ETL-CentralSquare

Bring CentralSquare Public Safety Suite Professional CAD locations into the TAK System

Setup🔗

Request a Pro Suite API user account from the agency administrator. The agency provides a Username and Password for a dedicated API service account - human user credentials should not be shared with the integration.
Ask the agency for the base URL of their Pro Suite deployment:
- Cloud hosted: https://{agency-subdomain}.centralsquarecloudgov.com
- On-premises: https://{agency-server}
Confirm with the agency that the account has been granted the CFS Core - Open permission (calls for service) and/or the Units - Open permission (AVL unit tracking), along with the underlying PSJ record permissions for the relevant dispatch agencies.
Provide the above information to the ETL CentralSquare Integration.

Configuration🔗

Field	Required	Description
`BaseURL`	Yes	Base URL of the Pro Suite deployment - ie `https://agency.centralsquarecloudgov.com`
`Username`	Yes	Pro Suite API user provisioned by the agency
`Password`	Yes	Password for the Pro Suite API user
`Domain`	No	Active Directory domain - only required for agencies using LDAP authentication
`DataType`	Yes	`Calls for Service` posts currently active CFS incident locations, `Units` posts AVL unit locations
`BoundingBox`	No	`minLon,minLat,maxLon,maxLat` of acceptable geocoded locations - ie `-105.4,39.5,-104.6,40.0`. Geocoded results outside of the box are discarded
`FallbackCoordinates`	No	`Latitude,Longitude` used for records that have no coordinates and could not be geocoded - ie `39.7392,-104.9903`
`DEBUG`	No	Print raw API responses in the layer logs

A single layer posts either calls for service or unit locations. To bring both into TAK, configure two layers against the same credentials - one with DataType: Calls for Service and one with DataType: Units.

The task exposes two named Output schemas - CADEvent (calls for service) and CADUnit (AVL units) - select the schema matching the layer's DataType in the CloudTAK Layer Schema & Styles panels.

Limitations🔗

Accounts enforcing multi-factor authentication are not supported - the API service account must be exempt from MFA.
Results are not filtered by Dispatch Agency or Incident Code - scope the API user's permissions at the agency to limit what is returned.
Calls for Service are limited to currently active calls.

How it Works🔗

Step	Endpoint	Notes
Authenticate	`POST /api/token`	OAuth 2.0 password grant. Returns a JWT used as a Bearer token
Calls for Service	`POST /api/cad/latest/cfs_core/search`	Paginated with `skip`/`limit`, 100 records per page
Units	`POST /api/cad/latest/units/search`	Paginated with `skip`/`limit`, 100 records per page

The Pro Suite token endpoint is aggressively rate limited and authenticating on every call will lock the integration out of API access. The Bearer token is therefore cached in the layer's ephemeral store and reused until an hour before it expires - the expires_in value returned by Pro Suite is honoured when present, otherwise the documented 24 hour default is assumed.

Every request carries the required From header so the agency can attribute API activity to this integration in the Pro Suite audit trail.

Latitude and longitude are read from the record itself (units) or from the nested GeneralAddress, Address or Location object (calls for service), and both the Latitude/Longitude and Lat/Lon spellings are accepted.

Calls for service that carry an address but no coordinates are geocoded via the CloudTAK Search API (GET /api/search/suggest then GET /api/search/forward) - this requires the search:read permission. When a BoundingBox is configured its centre is used to bias the search and any result outside of the box is rejected. Records that still have no acceptable coordinates are placed at FallbackCoordinates if configured, otherwise they are skipped. Dropdown values - { UniqueIdentifier, Description, Code } - are reduced to their human readable description for the CoT remarks.

This ETL is read-only against CentralSquare. It never creates, updates, or deletes records in the agency's CAD system.

CloudTAK Permissions🔗

Permission	Required	Purpose
`feature:*`	Yes	Post CAD call for service and unit locations to the map
`event:create`, `event:read`, `event:update`	No	Create and modify CoreEvents for CAD calls for service
`search:read`	No	Geocode call for service addresses that have no coordinates

Development🔗

Development Information

DFPC provided Lambda ETLs are currently all written in [NodeJS](https://nodejs.org/en) through the use of a AWS Lambda optimized Docker container. Documentation for the Dockerfile can be found in the [AWS Help Center](https://docs.aws.amazon.com/lambda/latest/dg/images-create.html)

npm install

Add a .env file in the root directory that gives the ETL script the necessary variables to communicate with a local ETL server. When the ETL is deployed the `ETL_API` and `ETL_LAYER` variables will be provided by the Lambda Environment

{
    "ETL_API": "http://localhost:5001",
    "ETL_LAYER": "19"
}

To run the task, ensure the local [CloudTAK](https://github.com/dfpc-coe/CloudTAK/) server is running and then run with typescript runtime or build to JS and run natively with node

ts-node task.ts

npm run build
cp .env dist/
node dist/task.js

### Deployment Deployment into the CloudTAK environment for configuration is done via automatic releases to the DFPC AWS environment. Github actions will build and push docker releases on every version tag which can then be automatically configured via the CloudTAK API. Non-DFPC users will need to setup their own docker => ECS build system via something like Github Actions or AWS Codebuild.

Info

This page is generated daily from the README of dfpc-coe/etl-central-square (last fetched 2026-10-08). Changes should be made in that repository.