How PDP Mobile was integrated with an access control system for barriers, intercoms, and Bluetooth access

Physical access does not break at the barrier. It breaks in the permissions.

A barrier can be working, an intercom can answer, and a camera can read a plate correctly. But if the app and the access control system understand differently who is allowed to open the gate right now, the system quickly turns into a collection of exceptions: a QR pass here, a resident card there, a license plate in one place, Bluetooth separately.

At PDP Mobile, we connected the mobile app to an access control system for physical access control: barriers, gates, intercoms, and Bluetooth access. The main challenge turned out not to be the "open" button, but the identifier model.

Before: access existed, but there was no single model

The initial pain looked like this: there are several physical access points and several identification methods, but the mobile app has to manage them as one system.

The access control system works with hardware: it opens the barrier, makes decisions for gates, handles the intercom, and checks access over Bluetooth. The app lives closer to the user: it deals with passes, linked data, and entry/exit flows.

The most visible scenario is the car one. A camera reads the license plate, the access control system checks whether there is a valid token for it, and the barrier opens automatically. The user does not press a button, does not look for a QR code, and does not call an operator. But for the system, this is still a full permission check, not just "the plate was seen, so open it."

Other identifiers live alongside that:

• QR pass tokens;
• license plate tokens;
• resident access cards;
• Bluetooth access from a phone.

They could not all be thrown into one bucket. Each type has its own lifecycle: how it is created, when it becomes active, how it is validated, and how it is revoked.

What changed in the integration

We set up the link between PDP Mobile and the access control system so that the app handles user flows and identifier state, while the access control system handles execution at the physical level.

If a QR pass appears in the app, a QR pass token is sent to the access control system with clear validation rules. If a user links a car, the access control system receives a license plate token that is later used when the camera reads the plate. If a resident card is needed, it is handled as a separate access type, not as "just another QR code."

A practical detail from the design phase: we really wanted to introduce a single accessToken and distinguish everything with one type field. The diagram looked neat. Then we got to access revocation — and the diagram stopped being neat. A QR pass, a license plate, and a resident card are revoked for different reasons and in different scenarios. If you blur those differences into one shared entity, the errors will not show up in the API; they will show up at a closed barrier.

So we separated validation and revocation rules by identifier type. It is less "beautiful" in the model, but it honestly reflects how access behaves.

After: the app manages access, the access control system opens the hardware

After the integration, PDP Mobile became the point through which access to physical infrastructure can be managed: barriers, gates, intercoms, and Bluetooth scenarios.

Before: access existed in separate mechanisms. The QR pass was one flow, the license plate was another, the resident card was a third, and Bluetooth was a fourth. Any change in permissions had to be carefully propagated to the access control system, otherwise the user saw one thing and the hardware made a different decision.

After: each identifier has its own lifecycle, and the mobile app and the access control system are synchronized on the entities that actually participate in granting access.

The car scenario is the clearest example. The camera reads the license plate, the access control system matches it to the license plate token, and the barrier opens automatically. For the user, it looks like a quick drive-through. For us, it is a chain of recognition, token verification, and a decision for a specific access point.

Where we had to be careful

In integrations like this, it is dangerous to think only about successful opening. The states where access must stop working are just as important.

For example, revoking a QR pass is not the same as revoking a resident card. Unlinking a license plate is not the same as disabling Bluetooth access. Outwardly, all of these actions look similar: "deny access." But internally they are different entities, different checks, and different consequences for the access control system.

That is why the main focus was on the lifecycle: creation, validation, current state, revocation. Not on a universal open button, but on making sure each access type follows its own path without mixing rules.

The next layer in systems like this usually starts where ambiguous states appear: the token has already been revoked in the app, but the physical access point still needs to receive that change. That is exactly why the identifier model is better designed before all the barriers, gates, and intercoms are connected to it.