Mosler Direct — Overview

Mosler Direct is Mosler's first-party integration surface. If you own your booking flow — a custom app, a booking engine, or an in-house property system — Mosler Direct is how you wire it to the locks. You shape one simple payload and POST it to a single URL; Mosler handles guest resolution, room lookup, and credential provisioning from there.

Unlike a PMS integration — where your existing PMS dictates the payload and Mosler adapts to it — with Mosler Direct you control the request shape, so it stays small and predictable. Mosler Direct can also deliver the credential straight to your guest over Mosler's WhatsApp/email channel, so credential delivery is optional work for you.

The integration loop

1. Map locations        GET  /api/v4/location/all
   (once, then on change)   → learn your room references

2. Create a booking     POST /webhook/t/:token
                            → 202 { eventId }   access provisioned async

3a. Pull the credential GET  /api/v4/bookings/:referenceId/access
        — or —
3b. Receive it pushed   Mosler → your callback URL  (and/or → guest via WhatsApp/email)

Step 1 is covered in Mapping Locations, step 2 in Creating Bookings, step 3a in Retrieving Access, and step 3b in Delivering Access.

Base URLs

Authentication

Mosler Direct uses two credentials depending on the surface you're calling.

Sending bookings — token URL (recommended)

Booking events are sent to a tokenized URL. The token is the whole credential — paste the full URL into your system and you're done.

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

A token comes in one of two scopes, and the scope decides whether you name the site in each payload:

A company-level URL means you configure Mosler once instead of once per property — adding a new site needs no new URL. It's the recommended shape for multi-property integrations; see identifying the site for the payload field.

Tokens are issued from the Mosler Admin portal (company-level from the Company page, site-level from the Site page). Treat the URL as a secret — anyone with it can submit booking events within its scope.

Sending bookings — header auth (alternative)

If you'd rather not put the credential in the URL, post to the provider endpoint and pass identifiers as headers. This path is always site-scoped — X-Site-Id is required, and there is no company-level equivalent:

POST https://webhook.mosler.in/webhook/generic
apikey:        YOUR_API_KEY
X-Company-Id:  <company id>
X-Site-Id:     <site id>

Reading locations & access — integration key

The /api/v4/* API (locations, access, and callback verification) authenticates with an integration key in the apikey header — a mk_live_… credential scoped to your company.

apikey: mk_live_your_integration_key

Integration keys live inside an Integration — a self-service container you create in the Mosler client portal for one partner connection. Each Integration holds its scope, its outbound callback config (URL + auth — see Delivering Access), and one or more inbound API keys that you issue, rotate, and revoke yourself. The same key authorises the whole flow: map locations, attach your own IDs, create bookings, and read access.

Response envelope (API)

The Location and Access APIs return Mosler's standard envelope:

{
    "message": "Human-readable status message",
    "code": 7000,
    "error": false,
    "data": {}
}

The webhook ingest endpoint instead returns 202 Accepted with { success, eventId, status } — see Creating Bookings.

Pages in this section