Visitor access adapter

A standalone adapter that lets a cloud visitor-registration front-end check people in, and re-issue their access credential, over HTTP — against a German physical-access platform where neither operation had ever existed outside the desktop client.

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 visit's validity 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 visitor platform already published a REST API for companies, visitors and visits. Check-in was not in it, and neither was showing a visitor their code a second time; both lived only in the desktop UI. A cloud front-end needed both as an API, and the vendor core was not allowed to change — which rules out the obvious answer of adding two endpoints where the rest of them already are.

What we built

POST /checkin
Validates the visit and the visitor, provisions a PIN or QR credential against the access layer, marks the visit checked in and stores the medium. Calling it twice returns the credential that already exists rather than issuing a second one.
GET /access-medium
Returns the credential already issued, read from the adapter's own store. Showing someone their code again costs one cheap read and never goes back into the vendor.
Validation before any side effect
Unknown identifiers are refused up front with a 422. A half-provisioned visitor — a person 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 access layer has confirmed the medium. There is no state in which the adapter 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 vendor core — which was the constraint the whole design had to respect.

Technical approach

Compose the vendor's published visitor API with the access-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 medium is persisted only once the access layer has confirmed it, which is what makes a 200 trustworthy. Retrieval reads the adapter's store instead of calling back into the vendor, so the cheap operation stays cheap. The adapter 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.