eZee Integration

This page is for properties running eZee Absolute or eZee Centrium. eZee sends its native reservation events to Mosler and Mosler provisions/revokes access automatically — no payload shaping on your side. You configure room mappings once, point eZee's webhook at your Mosler URL, and you're live.

---

Before you start

---

Endpoint

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

The token encodes your company, site, and the eZee provider. A header-authenticated path also exists:

POST https://webhook.mosler.in/webhook/ezee
X-Company-Id: <company id>
X-Site-Id:    <site id>
Content-Type: application/json

---

Payload shape

eZee sends a single JSON object. Guest and booking detail lives in data.Reservations.Reservation[].BookingTran[].

{
  hotel_code: string             // must match the site's hotel_code in Mosler
  operation: string              // see Operation Mapping
  data: {
    Reservations: {
      Reservation: [
        {
          UniqueID: string
          FirstName?: string      // Reservation-level guest (fallback)
          LastName?: string
          Mobile?: string
          Email?: string
          BookingTran: [
            {
              SubBookingId: string
              TransactionId: string     // becomes Mosler referenceId
              Status: string
              CurrentStatus: string
              RoomID?: string           // matched against room.metadata.ezee_metadata.RoomID
              RoomName?: string         // fallback room match
              Start: string             // YYYY-MM-DD
              End: string               // YYYY-MM-DD
              ArrivalTime?: string      // HH:mm (IST)
              DepartureTime?: string    // HH:mm (IST)
              FirstName?: string        // BookingTran-level guest (preferred)
              LastName?: string
              Mobile?: string
              Email?: string
            }
          ]
        }
      ]
    }
  }
}

Key fields

Guest fields at BookingTran level take priority over the same fields at Reservation level.

---

Operation mapping

Status values

The Status / CurrentStatus field disambiguates each operation:

---

Reference ID

referenceId = hotel_code + ":" + BookingTran.TransactionId

Example: hotel_code GOSL01 + TransactionId TXN-84291 → GOSL01:TXN-84291. eZee reuses the same TransactionId across follow-up events, so Mosler can locate the original booking.

Multi-segment bookings: when a stay spans multiple rate segments, eZee sends several BookingTran entries sharing a SubBookingId. Mosler merges contiguous segments into one booking and tracks the extra transaction IDs as aliases — you don't need to do anything.

---

Dates & times

Dates are YYYY-MM-DD; times (ArrivalTime, DepartureTime) are HH:mm or HH:mm:ss, all treated as IST (Asia/Kolkata, UTC+5:30).

Room matching

The adapter resolves the room by, in order:

1. RoomID → exact match on room.metadata.ezee_metadata.RoomID
2. RoomName → fallback match on room.metadata.ezee_metadata.RoomName

eZee usually sends both. Ensure rooms carry matching ezee_metadata before going live, or events fail with Room not found.

---

Request example — new reservation

fetch('https://webhook.mosler.in/webhook/t/<your-token>', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
        hotel_code: 'GOSL01',
        operation: 'RESERVATION',
        data: {
            Reservations: {
                Reservation: [
                    {
                        UniqueID: 'SRI001',
                        FirstName: 'Raj',
                        LastName: 'Mehta',
                        Mobile: '+919888888888',
                        Email: 'raj.mehta@example.com',
                        BookingTran: [
                            {
                                SubBookingId: 'SRI001-1',
                                TransactionId: 'TXN-84291',
                                Status: 'New',
                                CurrentStatus: 'Confirmed Reservation',
                                RoomID: 'EZ-ROOM-204',
                                RoomName: 'Room 204',
                                Start: '2025-07-18',
                                End: '2025-07-22',
                                ArrivalTime: '14:00',
                                DepartureTime: '11:00',
                            },
                        ],
                    },
                ],
            },
        },
    }),
});

Request example — cancellation

Send the same TransactionId with the cancel operation:

body: JSON.stringify({
    hotel_code: 'GOSL01',
    operation: 'VOID_CANCEL_NOSHOW_RESERVATION',
    data: {
        Reservations: {
            Reservation: [
                {
                    UniqueID: 'SRI001',
                    BookingTran: [
                        {
                            SubBookingId: 'SRI001-1',
                            TransactionId: 'TXN-84291', // same as original RESERVATION
                            Status: 'Cancelled',
                            CurrentStatus: 'Cancelled',
                        },
                    ],
                },
            ],
        },
    },
});

---

Response

Mosler returns 202 Accepted with an eventId when the event is queued (or 400 on a validation error). Provisioning is asynchronous — track it with event status, then read or receive the credential via Retrieving Access / Delivering Access.

{
    "success": true,
    "eventId": "a3f9d2e1-84c7-4b56-9f13-0d2e4c8a1b7f",
    "status": "QUEUED",
    "message": "Event received and queued for processing"
}