Honeywell Pro-Watch DTU REST
Honeywell·AE_HSc_ProWatchDTU_RestConnectorGuide
Overview
The Pro-Watch DTU REST connector integrates AlertEnterprise Guardian with Honeywell Pro-Watch 6.x via Pro-Watch's modern RESTful DTU API — replacing the older SOAP-based honeywell-pro-watch-dtu integration path. This is the recommended connector for new Pro-Watch deployments on supported 6.x versions.
Unlike the HSDK + JDBC hybrid path (honeywell-prowatch) or the SOAP DTU path (honeywell-pro-watch-dtu), this connector uses AE's generic REST connector framework (extractor class com.alnt.platform.core.connector.rest.commons.IRESTConnectorInterface) and is driven entirely by URL templates configured per operation. Each capability (create user, lock user, assign badge, etc.) has its own configurable endpoint System Parameter, allowing customers to point the connector at whatever Pro-Watch REST surface their deployment exposes.
Pro-Watch terminology mapping for this connector is also slightly different: Roles are called ClearCodes, Credentials are called Cards, and User Accounts are called Badges in the API — the connector exposes these as Manage User Roles (ClearCodes), Assign Credential (Cards), and Create User Accounts (Badges) operations.
Architecture
Composed from this connector's actors + edges. Trust zones are color-coded; trust crossings render as thicker lines.
Authentication
1 method supported
The Pro-Watch DTU REST API authenticates clients via mutual TLS — the AE-side connector presents a client certificate that the Pro-Watch server validates against its configured trust store. The connector's Authorization system parameter holds the bearer / token if the deployment layers additional auth atop mTLS.
Endpoints
15 endpoints exercised by the connector
| Method | Path | Description | Category |
|---|---|---|---|
| POST | {CREATE_USER0 endpoint} | Create User Account (badge-level account creation). | provisioning |
| PUT | {UPDATE_USER0 endpoint} | Update User Account. | provisioning |
| DELETE | {DELETE_USER0 endpoint} | Delete User Account. | deprovisioning |
| POST | {LOCK_USER0 endpoint} | Lock User Account. | lifecycle |
| POST | {UNLOCK_USER0 endpoint} | Unlock User Account. | lifecycle |
| GET | {SEARCH_USER0 endpoint} | Search / lookup users for reconciliation. | query |
| POST | {ASSIGN_BADGE0 endpoint} | Assign Credential (Card) to a user. | provisioning |
| PUT | {UPDATE_BADGE0 endpoint} | Update Credential validity dates. | provisioning |
| POST | {ACTIVATE_BADGE0 endpoint} | Activate Credential. | lifecycle |
| POST | {DEACTIVATE_BADGE0 endpoint} | De-activate Credential. | lifecycle |
| DELETE | {REMOVE_BADGE0 endpoint} | Remove Credential from user. | deprovisioning |
| POST | {ADD_ROLE0 endpoint} | Add Role (ClearCode) to user. | provisioning |
| DELETE | {REMOVE_ROLE0 endpoint} | Remove Role (ClearCode) from user. | deprovisioning |
| GET | {GET_ALL_ROLES0 endpoint} | Fetch all available roles (ClearCodes). | query |
| GET | {GET_ALL_USERS0 endpoint} | Fetch all users for full reconciliation. | query |
Prerequisites
Everything that must be in place for this connector to work, with the owner who's responsible.
Pro-Watch 6.x with REST DTU API enabled
customerA Pro-Watch 6 or 6.5 deployment with the RESTful DTU API enabled. The Instance URL system parameter must point to the API base (example from guide: http://172.16.38.106:8734/pwapi).
mTLS client certificate provisioned
jointAE-side client certificate provisioned and trusted by the Pro-Watch DTU REST API's mTLS configuration. This is the primary auth mechanism — without a valid client cert the API rejects all requests.
Per-operation endpoint URLs configured
aeAll 15+ operation endpoints (CREATE_USER0, UPDATE_USER0, DELETE_USER0, LOCK_USER0, UNLOCK_USER0, SEARCH_USER0, ASSIGN_BADGE0, UPDATE_BADGE0, ACTIVATE_BADGE0, DEACTIVATE_BADGE0, REMOVE_BADGE0, ADD_ROLE0, REMOVE_ROLE0, GET_ALL_ROLES0, GET_ALL_USERS0) must be configured as System Parameters. This connector's flexibility is also its setup burden — there is no single API root.
Identifier-key system parameters set
aeThe connector requires User Identifier Key, Badge Identifier Key, Created User Identifier Key, and Role Identifier Key system parameters configured to map API response keys back to AE-side identifiers.
Run Database Scripts in HSC Application Table
aePer the connector guide's Chapter 3 installation step, database scripts must be executed in the HSC application table for the connector to function correctly. Run as part of connector deployment.
Known limitations
Documented constraints to set customer expectations before deployment.
15+ endpoint URLs to configure (high setup burden)
informationalBecause the connector uses the generic REST connector framework with per-operation endpoint System Parameters, customers must configure each endpoint URL individually. A misconfigured endpoint shows as a single-operation failure rather than a global connector failure, which can make initial diagnosis more painful than for connectors with a single API root.
PACS specifics
Pro-Watch 6.x cardholder model — see honeywell-prowatch for the underlying schema. The REST API surfaces this through user / badge / card resources rather than table-level access.
Same Pro-Watch badge-level role assignment as the other Pro-Watch connectors, but exposed through REST endpoints with ClearCode as Pro-Watch's term for the role primitive.
Single Pro-Watch 6.x instance per AE→Pro-Watch DTU REST connector.
- Topology
- on-prem
- Event model
- polling
- Anti-passback
- unknown
- Holiday schedules
- unknown
- src/connectors/pro-watch-dtu-rest/source.pdf — Full connector guide — 45 pages, revision 2.0 dated 2025-11-19
- src/connectors/pro-watch-dtu-rest/source.pdf — p7 — Supported Version
- src/connectors/pro-watch-dtu-rest/source.pdf — p7 — Connector Architecture