
[ Blog ]
The vendor seam: how ENTRIX stays independent of the PMS and the lock
Every property runs a different booking system, lock and channel manager. ENTRIX keeps them behind three ports, and makes each adapter say out loud what it cannot do.
An identity platform for properties is only as portable as its least portable dependency. ENTRIX has to read reservations from a property management system, turn a verified guest into a working credential on a door, and, increasingly, push availability to the channels that sell the room. No two properties buy those three things from the same vendors. So the seam between ENTRIX and the vendor is designed as carefully as the verification itself.
The design is ports and adapters. There are three ports: reservation source, door lock and channel manager. Each is a contract written in the product's vocabulary, never a vendor's. There is no field in the door-lock port named after any lock maker's passcode parameter, and there will not be one. An adapter translates one vendor into that vocabulary, and the rest of the application speaks only to the port.
The part that does the work is the capability declaration. No two booking systems support the same operations: one has webhooks, one does not; one can filter by modification time, one cannot. Discovered at runtime, those differences arrive as an error, an empty list or, worst of all, a parameter the vendor's API accepts and silently ignores, so a caller believes it received a delta when it received everything. A boolean in a declaration cannot be silently ignored. Every ENTRIX adapter must answer every capability in its port's vocabulary, true or false; omission is rejected. When a port grows a new capability, every existing adapter fails validation until someone decides its answer.
Door locks needed one more idea. Whether a provider supports remote unlock is not an answerable question, because remote unlock travels from the cloud to a powered bridge near the door and then to the lock over short-range radio. On one deployment just over half of the locks had a bridge in range. So the door-lock port declares capability at two levels, what the vendor's API can express and what this particular door can do, and a caller runs a pre-flight check against the door before taking any step it cannot take back.
The same port makes a rule about secrets structural rather than vigilant. A credential record, meaning the door, the type, the validity window and a label, is safe to list, store and log. The code itself exists only in the value returned at the moment of issue, exactly once. The fields an adapter may return are a closed list, and the conformance suite fails any adapter that returns anything else. The port also declares what hardware cannot do remotely: fingerprint enrolment is in the vocabulary and declared false, because a fingerprint needs the finger at the door.
Conformance suites turn the contract into evidence. Each port has one, and each adapter runs it. That is what the status in the ENTRIX provider catalog means. Cloudbeds and TTLock are live in production. Atrium, a white-labelled QloApps deployment, and Nuki locks pass their ports' full suites and need only a subscriber's credentials and ID mapping. The Channex channel-manager adapter is in the same state. A Meituan adapter passes the suite too, but three facts from Meituan's own specification are still outstanding, so the catalog lists it as planned and the adapter refuses those calls rather than guessing them.
Ports decay by being bypassed, not by being wrong. Someone needs one field the port does not expose, imports the vendor client just here, and within a quarter the abstraction is decorative. ENTRIX guards against that with a ratchet: a test lists every file still allowed to import a vendor client directly, fails on any new one, and fails again if a listed file stops importing, so the list can only shrink. It is a progress bar a reviewer can read without reading a diff.
The result is a platform where adding a PMS is a bounded piece of work with a definition of done: write the adapter, answer every capability honestly, pass the suite. That is what vendor independence means in practice. Not a claim on a slide, but a contract, a test and a number that goes down.
Press & analyst inquiries
Reach the Opsian press desk.
For interviews, briefings, and analyst access — get in touch and we will route the request.
Response within 24 hours · Sales@opsian.io

