Building Security Integration

A standalone integration service for a building-security platform. It lets a cloud check-in front-end check people in, and re-issue their access credential, over HTTP — two operations that had only ever existed inside the platform's desktop client, on a system we were not allowed to modify.

Java
Spring Boot
REST
TLS
Windows service

An office campus gate at night after rain, the canopy and the lit windows behind it, with a time window drawn across the frame as a thin overlay.

Role: Integration design, build and delivery
Built with: Java · Spring Boot · REST · Windows service
Year: 2025

The challenge

The security platform already published a REST API for its core records. Checking someone in was not in it, and neither was showing a person their credential a second time; both lived only in the desktop client. A cloud front-end needed both as an API, and the platform itself could not be changed — which rules out the obvious answer of adding two endpoints next to the ones that already existed.

What we built

Check-in as one API call
Validates the request against the platform's records, provisions a PIN or QR credential through the security system, marks the person checked in and stores the credential. Calling it twice returns the credential that already exists rather than issuing a second one.
Credential retrieval as a cheap read
Returns the credential already issued, read from the integration's own store. Showing someone their code again costs one cheap read and never goes back into the security platform.
Validation before any side effect
Unknown identifiers are refused up front with a 422. A half-provisioned person — someone who exists in one system and not the other — is the failure this ordering exists to prevent.
A 200 means a real credential
The record is written only after the security system has confirmed the credential. There is no state in which the integration reports someone as checked in and the door disagrees.
One public surface, and it is locked down
TLS, basic authentication and an IP allowlist on the single internet-facing endpoint. Its own schema and database user inside the existing instance, with secrets encrypted at rest.
Shipped as a service, versioned on its own
A signed Windows installer with a bundled runtime, running as a Windows service. It updates without anyone touching the platform it integrates with — which was the constraint the whole design had to respect.

Technical approach

Compose the platform's published API with its client libraries, and put the composition in a service of its own rather than inside anything that ships with the platform. Identifiers are checked before anything is provisioned, so a bad request costs nothing. The credential is persisted only once the security system has confirmed it, which is what makes a 200 trustworthy. Retrieval reads the integration's own store instead of calling back into the platform, so the cheap operation stays cheap. The service owns its schema and database user inside the existing database instance, keeps its secrets encrypted at rest, and ships as a signed Windows installer with a bundled runtime so it can be versioned independently of the platform it sits beside.