Introduction

These are the Mosler developer docs. They explain how to connect your system to Mosler so that booking a room automatically gives the guest access to it — and checking out automatically takes that access away.

This page covers what Mosler does and how to read the rest of the docs. If you already know the model, jump straight to Mosler Direct (our first-party integration) or to a PMS integration.

---

What Mosler does

Mosler is a smart-access platform for hospitality. It sits between your booking system and the physical smart locks on your property. When a guest is booked into a room, Mosler provisions a credential on the right lock; when the stay ends or is cancelled, Mosler revokes it. No staff member has to touch the lock.

To do this, Mosler keeps a replica of your property's physical layout and the devices installed on it. You map your rooms to Mosler once; after that, every booking event just refers to a room (and optionally a bed), and Mosler already knows which lock(s) that means.

---

The location model

Mosler models every property as a six-level hierarchy. Smart locks (devices) are bound to the Room level (the entrance door) and, for shared/dormitory properties, to the Bed level (an in-room cabinet/locker).

Company
 └── Site          e.g. "Delhi", "Goa Annex"
      └── Building  e.g. "Main Tower", "West Wing"
           └── Floor e.g. "Ground", "First"
                └── Room  e.g. "101"          ← door lock
                     └── Bed   e.g. "A", "B"  ← cabinet lock (hostels/dorms)

You don't send Mosler internal IDs on every booking — you send a room number (and a bed number where relevant), and Mosler resolves it against this replica. See Mapping Locations for how to read the hierarchy programmatically and keep your room references in sync.

---

Access types

When a booking is created you tell Mosler which kind of credential to provision via access_type. Mosler then issues it on every lock bound to the booked location.

You can request more than one type for a booking (e.g. ["EKEY", "PASSCODE"]). How you later retrieve or receive these credentials is covered in Retrieving Access and Delivering Access.

---

Two ways bookings reach Mosler

1. Mosler Direct — our first-party API

If you control your own booking flow (a custom app, a booking engine, an in-house PMS), you integrate with Mosler Direct. You shape a simple, well-documented payload and send it to a single webhook URL. Mosler Direct can also deliver credentials straight to the guest over Mosler's WhatsApp/email channel, so you don't have to build delivery yourself. Start at Mosler Direct → Overview.

2. PMS integration — your existing PMS sends events

If your property already runs a supported Property Management System, you don't build anything — the PMS sends its native event format to Mosler and we translate it. Supported today: eZee and Hotelogix. See PMS Integrations.

Both paths converge on the same engine: an event is received, validated, queued, and processed by a worker that resolves the guest, finds the room, writes the booking, and provisions device access. The Architecture section documents that internal pipeline.

---

How credentials leave Mosler

Once access is provisioned, you get the credential to the guest in one of two ways:

• Pull — your system asks Mosler for the credential when it needs it. See Retrieving Access.
• Push — Mosler sends it to you (a signed callback to your URL) or directly to the guest (WhatsApp/email), with no polling. See Delivering Access.

---

Map of these docs