Why PMS Providers Should Build the Integration — Not Us

A smarter, faster, and more sustainable approach to access-control integrations

Integrating a Property Management System (PMS) with an access-control provider should be simple, reliable, and seamless for the hotels that rely on both systems every day. In reality, however, the work required to pull data from a PMS can be surprisingly complex. Every PMS has its own internal rules, workflows, edge cases, and data models — and understanding them well enough to build a stable integration often takes far longer than anyone expects.

For this reason, we strongly recommend that PMS providers build the integration toward our API, rather than having us build toward theirs. This approach consistently produces better performance, reduces long-term maintenance, and creates a far smoother experience for hoteliers.

Below are the core reasons why.

1. Our API Is Simple, Consistent, and Fast to Implement

Our API (https://lock.inlet.no/api/documentation) is deliberately designed to be:

Small and easy to understand
Predictable, with clean data structures
Purpose-built for access control, not a multipurpose system
Quick to test and quick to deploy

Most PMS APIs, on the other hand, are large, multi-domain systems with many endpoint groups, legacy structures, and undocumented workflows. It may take significant time for an external developer to understand how your reservations, groups, room states, notes, arrival times, updates, and special cases actually work in practice.

Your team already knows your PMS and its internal logic — so you can build a correct integration much faster than we can.

2. PMS-Initiated Integrations Are Event-Driven, Not Poll-Driven

When we integrate with a PMS, we typically have no choice but to pull data at regular intervals:

Every X minutes, request all changed reservations
Re-download room states
Check for arrivals, departures, cancellations, changes, and notes

This approach is unavoidable when the PMS is built first and we have no mechanism to receive live updates.

Polling has downsides:

It introduces delays, because we only see changes after the next polling cycle.
It increases API traffic on both sides.
It creates race conditions, because updates may happen in between cycles.
It is less reliable than immediate, event-driven notifications.

When you push updates to us as they occur, everything becomes instant.
Access is granted right away. Changes propagate immediately. The hotel gets a faster and more responsive system.

3. Better Experience for Hotels and Their Staff

Hotels want two things from any integration:

It must work reliably, every time.
It must feel seamless, with no delays or confusion.

When the PMS builds the integration:

Reservation updates happen in real time
Keys activate exactly when staff expect
Cleaning schedules stay perfectly synchronized
The front desk has fewer surprises and fewer support issues

Hotels notice the difference — and they judge the PMS by the reliability of the integration.

4. Fewer Support Cases and Lower Maintenance Costs

When we build an integration against your API, we inevitably run into:

Missing documentation
Undocumented workflow rules
Special cases (group reservations, conferences, room renumbering, etc.)
Data fields that don’t behave as expected
Complex internal business logic
API changes over time

Each of these adds long-term maintenance and generates support requests from hotels.

When the PMS team builds the integration:

You already know your own business rules
You know which endpoints are reliable
You can handle internal changes without breaking the integration
You minimize support overhead for both companies
You maintain full control over the user experience

This produces a far more stable integration with significantly fewer hotel-facing issues.

5. A PMS-Developed Integration Is More Scalable

As you add more hotels, chains, or features, you want an integration that:

Scales cleanly
Is easy to update
Reflects new PMS functionality
Works consistently across customer types

If we build a one-off integration from the outside, it becomes much harder to evolve it over time.
But when the PMS builds the integration:

You can extend it as your system evolves
You can introduce new data fields or workflows whenever needed
You ensure compatibility across all versions of your product

It becomes a long-term asset, not a one-time custom project.

6. Stronger Competitive Positioning for the PMS

Hotels increasingly expect modern, automated, connected systems. A PMS that provides high-quality native integrations becomes far more attractive than one relying on external partners to reverse-engineer its API.

By owning the integration, the PMS can:

Offer a branded, polished, official solution
Provide faster onboarding for hotels
Reduce the need for hotels to work with multiple vendors
Strengthen its ecosystem and market position

This is a clear competitive advantage.

Conclusion

Building the integration in the PMS → toward our API is the best solution for:

The PMS
The hotels
The integration vendor
The end-users who rely on seamless automation

Our API is intentionally simple, predictable, and easy to integrate with.
Your API — as with any PMS — is naturally complex, because your product solves many problems at once.

The integration is faster, more reliable, more maintainable, and more scalable when you drive the connection, not us.

Why PMS Providers Should Build the Integration