Common Integrations: How-To Guide

The most common integration patterns between LabKey’s access control and property management systems, booking platforms, and payment systems, with real examples already in production.

LabKey’s API layer is stable and has been used in production for years to connect access control to management software, PMS platforms, booking systems, and payment systems. This guide collects the most common integration patterns — based on real cases already in production, described here in generic form — to help you get oriented quickly before designing your own integration.

How to start an integration

There are three possible approaches, depending on the technical resources available:

Self-service: build it yourself starting from the complete API documentation, also available in interactive format on Postman.
SDK and starter code: the LabKey team can provide ready-made SDKs and code snippets for the most common patterns, to speed up development.
Custom integration: the LabKey team can build the integration on your behalf, tailored to your needs.

Most common integration patterns

Below are the most recurring integration patterns, drawn from integrations actually running in production (some for several years), described here in generic form.

Automatic credential generation from a booking management system

The booking management system (a hotel PMS, sports-facility or coworking software) notifies the system when a booking or check-in is completed; the system automatically generates a credential (code, NFC key, or QR code) valid only for the stay or booking period, and sends it to the user.

Calls involved: AddUser → GrantAccess → getqrcode or UpdatePinpad → sendemail — see the Users, Access and Permissions, and General sections of the API documentation.

A typical pattern for integrating with cloud-based hospitality management systems, such as Passepartout, Hotel in Cloud, or TeamSystem Hospitality (already LabKey partners).

Authorization check with an external system before opening

In some contexts (for example, public bodies with their own authorization system) the opening request doesn’t come directly from LabKey: an external service first checks authorization with the third-party system and, only based on the outcome, sends the opening command. Useful when the authorization logic needs to stay centralized in an existing system.

Pay-per-use access with rechargeable credit

An external member area lets the user top up a credit balance (e.g. for entries, services, or metered consumption); the remaining credit is automatically deducted at each access, with the credential automatically disabled once the balance runs out.

Calls involved: getcredits, recharge, getprices — see the Credits section.

Public self-registration with operator confirmation

A public page lets the user register on their own; the system generates a provisional code, which is only permanently activated after manual confirmation by an operator.

Calls involved: AddUser (created disabled) → operator confirmation → GrantAccess.

Opening triggered by no-code automations or online forms

Filling out an online form (e.g. JotForm, already a LabKey partner) or an automation on no-code platforms (e.g. Zapier, Make) can directly trigger the opening of a gate, through the API PRO calls.

Online payment that generates access

A website or e-commerce store with integrated payment (e.g. Stripe) automatically generates and sends an access code once a transaction is completed.

Opening from your own app via QR code

If the opening needs to happen from your own app rather than a physical reader, the typical flow is: AddUser → GrantAccess → getqrcode. The client’s app displays or processes the returned QR code to complete access.

An alternative worth considering carefully: if you’d rather act directly on the control unit’s relay with your own external device (the contact is dry, normally open — NO — and can be triggered in parallel without issues), you bypass LabKey’s API layer entirely: no authentication, no logs, none of the panel’s features. It’s a valid choice if the authorization logic is already handled elsewhere, but it should be made knowing what you’re giving up.

Coworking and shared spaces

User groups with customizable time slots, temporary access via QR code, entry counters, and remote credential revocation are all native features of the system, also available via API to integrate them with a website or a space-booking management system.

Technical prerequisites

Authentication (Bearer token, secret key associated with the authorized IP) is described in the Authentication section of the API documentation. Two aspects to keep in mind when planning your integration:

API activation applies to all control units associated with the panel: it can’t be enabled for only a selection of them.
A dedicated test environment is available on request, to validate your integration before going into production.

Service levels: Standard and PRO

The Standard API service covers most of the scenarios described above. The API PRO service adds remote opening from external software via dedicated calls, plus advanced monitoring with API call logging.

Your platform isn’t listed among the partners?

That’s not a problem: the patterns described above apply just the same to platforms not yet listed in the public integrated partners directory — for example, major short-term rental channel managers like Lodgify aren’t a documented integration yet, but can be integrated using the same standard pattern.