Hotelogix Integration
This page is for properties running Hotelogix. Hotelogix pushes its native reservation events to Mosler and Mosler provisions/revokes access automatically — no payload shaping on your side. Configure room mappings once, point Hotelogix at your Mosler URL, and you're live.
Before you start
| Step | What to configure |
|---|---|
| Site identity | The site's hotel identifier must match Hotelogix's hotelId |
| Room mapping | Each Mosler room needs metadata.hotelogix_metadata.id set to Hotelogix's numeric roomId |
| Webhook URL | Paste your Mosler token URL into Hotelogix's notification settings |
Endpoint
POST https://webhook.mosler.in/webhook/t/<your-token>
A header-authenticated path also exists:
POST https://webhook.mosler.in/webhook/hotelogix
X-Company-Id: <company id>
X-Site-Id: <site id>
Content-Type: application/json
Payload shape
Hotelogix sends a single object with a top-level hotelogix key. The operation is in hotelogix.request.methodName; booking data is in hotelogix.response.data.bookings[].reservations[].
{
hotelogix: {
msgId: string
datetime: string // ISO 8601 — when the event was generated
request: {
hotelId: string
methodName: string // see Operation Mapping
}
response: {
hotelId: number // numeric hotel ID — first part of referenceId
data: {
bookings: [
{
reservations: [
{
id: string // reservation ID — second part of referenceId
code: string // confirmation code
ciDate: string // YYYY-MM-DD (fallback if no stays)
coDate: string // YYYY-MM-DD (fallback if no stays)
status: string
stays: [
{
fromDate: string // YYYY-MM-DD (preferred check-in)
toDate: string // YYYY-MM-DD (preferred check-out)
roomId: string // matched against room.metadata.hotelogix_metadata.id
}
]
guests: [
{
isPrimary: string // "1" = primary guest (preferred)
firstName: string | null
lastName: string | null
mobile: string | null
email: string | null
}
]
}
]
}
]
}
}
}
}
Key fields
| Field | Required | Description |
|---|---|---|
request.methodName | Yes | Hotelogix operation — see mapping |
response.hotelId | Yes | Numeric hotel ID — first part of referenceId |
reservations[].id | Yes | Reservation ID — second part of referenceId |
stays[0].roomId | Yes | Matched against room.metadata.hotelogix_metadata.id |
stays[0].fromDate / toDate | Yes | Stay dates (reservation.ciDate/coDate are fallbacks) |
Operation mapping
Hotelogix methodName | Mosler event |
|---|---|
reserve | BOOKING_CREATE |
checkin | BOOKING_CHECKIN |
checkout | BOOKING_CHECKOUT |
cancel | BOOKING_CANCEL |
roomchange | BOOKING_UPDATE |
| (anything else) | BOOKING_UPDATE |
Reference ID
referenceId = hotelogix.response.hotelId + ":" + reservation.id
Example: hotelId 123456789 + id RES-84291 → 123456789:RES-84291. Hotelogix reuses the same reservation.id across follow-up events so Mosler can locate the original booking.
Guest selection
Mosler uses the primary guest — the entry with isPrimary === "1". If none is marked primary, the first guest in the array is used. The selected guest's firstName, lastName, mobile, and email are mapped to the booking.
Dates & times
Dates are YYYY-MM-DD in local hotel time; Hotelogix doesn't send a time component, so Mosler applies defaults:
| Date | Source | Default time |
|---|---|---|
| Check-in | stays[0].fromDate (or reservation.ciDate) | 05:30:00 UTC |
| Check-out | stays[0].toDate (or reservation.coDate) | 08:30:00 UTC |
Defaults are company-configurable. Dates come from stays[0] when present, falling back to reservation.ciDate / coDate.
Room matching
stays[0].roomId → exact match against room.metadata.hotelogix_metadata.id
Rooms must be configured in Mosler with matching hotelogix_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({
hotelogix: {
msgId: 'msg-001',
datetime: '2025-07-10T10:00:00',
request: { hotelId: '123456789', methodName: 'reserve' },
response: {
hotelId: 123456789,
data: {
bookings: [
{
reservations: [
{
id: 'RES-84291',
code: 'CONF-001',
ciDate: '2025-07-18',
coDate: '2025-07-22',
status: 'RESERVED',
stays: [
{
fromDate: '2025-07-18',
toDate: '2025-07-22',
roomId: 'HLX-ROOM-204',
},
],
guests: [
{
isPrimary: '1',
firstName: 'Raj',
lastName: 'Mehta',
mobile: '+919888888888',
email: 'raj.mehta@example.com',
},
],
},
],
},
],
},
},
},
}),
});
Request example — cancellation
Send the same reservation.id with methodName: 'cancel':
body: JSON.stringify({
hotelogix: {
msgId: 'msg-002',
datetime: '2025-07-12T09:00:00',
request: { hotelId: '123456789', methodName: 'cancel' },
response: {
hotelId: 123456789,
data: {
bookings: [
{
reservations: [
{
id: 'RES-84291', // same as original reserve
code: 'CONF-001',
status: 'CANCELLED',
stays: [
{
fromDate: '2025-07-18',
toDate: '2025-07-22',
roomId: 'HLX-ROOM-204',
},
],
guests: [
{
isPrimary: '1',
firstName: 'Raj',
lastName: 'Mehta',
mobile: '+919888888888',
email: 'raj.mehta@example.com',
},
],
},
],
},
],
},
},
},
});
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"
}