PMS Integrations — Overview

If your property already runs a supported Property Management System (PMS), you don't build an integration — your PMS does the talking. The PMS sends its native reservation events (create, check-in, check-out, cancel, …) to Mosler, and Mosler translates them into bookings and provisions device access automatically.

This is the difference from Mosler Direct: there, you shape the payload; here, your PMS shapes it and Mosler adapts. Everything after ingestion — guest resolution, room lookup, access provisioning, and how you retrieve or receive credentials — is identical across all providers.

---

Supported providers

Running a PMS that isn't listed? Mosler adds adapters as customers onboard — talk to your Mosler representative.

---

How it works

Your PMS ──native event──► Mosler webhook ──normalize──► queue ──► worker
                              (per-provider adapter)              provisions access

1. Your PMS posts its native payload to a Mosler token URL for your account.
2. A provider adapter normalises that payload into Mosler's internal booking event — mapping the PMS's operation names to Mosler actions and extracting room, dates, and guest.
3. From there it's the shared pipeline documented in Architecture.

Endpoint

Each provider has its own path; in practice you'll be given a tokenized URL to paste into your PMS's webhook settings:

POST https://webhook.mosler.in/webhook/t/<your-token>

The token encodes your company, site, and provider, so the PMS only needs the URL. (Header-authenticated paths POST /webhook/ezee and POST /webhook/hotelogix also exist for setups that send X-Company-Id / X-Site-Id.)

---

What every provider shares

• Reference ID format — Mosler builds a stable booking key as HotelCode:TransactionId (the PMS's own hotel + reservation identifiers). Mosler uses it to match follow-up events to the original booking. You never construct it.
• Room matching — the PMS sends its own room identifier. Mosler matches it against each room's metadata.<provider>_metadata in the replica, so rooms must be configured in Mosler with the provider's room IDs before going live. This is the single most important onboarding step.
• Asynchronous processing — events are accepted (202), queued, and processed in the background. Status is trackable per event — see Event Lifecycle.
• Access is provider-agnostic — once a booking exists, retrieving and delivering credentials works the same whether the booking came from eZee, Hotelogix, or Mosler Direct.

---

Onboarding checklist

1. Configure each room in Mosler with its provider room ID (metadata.<provider>_metadata).
2. Set the site's hotel_code to match the PMS.
3. Paste the Mosler token URL into your PMS's webhook/notification settings.
4. Send a test reservation and confirm it reaches COMPLETED via event status.

See the provider pages for exact payloads and field mappings: eZee · Hotelogix.