Mobile Key SDK

Most Mosler credentials are passcodes or cards — your guest receives a PIN or taps an RFID card, and your integration is just data (Retrieving Access covers those). The e-key credential type is different: the guest's phone becomes the key, opening the lock over Bluetooth. Operating a Bluetooth lock requires running code on the device next to it, and that's what the Mobile Key SDK is for.

The SDK is distributed by Mosler on request for iOS and Android (and React Native). Contact your Mosler representative to get the package and platform credentials. This page explains the integration contract so you know what to expect before you start.

Why an SDK is needed

A passcode can be delivered as text. A Bluetooth unlock cannot — it's a live radio exchange between the phone and the lock that must happen within a few metres of the door. The SDK encapsulates that exchange so your app never has to:

• speak any lock vendor's Bluetooth protocol,
• manage pairing, encryption, or clock synchronisation with the lock,
• know which hardware vendor a given lock uses.

Mosler abstracts the lock manufacturer entirely. Your app passes opaque credential data to the SDK and calls "unlock" — the SDK does the rest.

The credential contract

When a booking has an e-key, the e-key endpoint returns two fields per lock:

Both are required to initialise an unlock, and both should be treated as credentials — store and transmit them as securely as a passcode. They are valid only for the booking's validFrom→validUntil window.

Integration flow

The end-to-end shape is the same on every platform:

Your backend                    Your mobile app                 Mosler SDK
     │                                │                              │
     │  GET …/access/e-key            │                              │
     │  (apikey, server-side)         │                              │
     │ ─────────────────────────────► │                              │
     │  { lockData, lockMac, … }      │                              │
     │ ◄───────────────────────────── │                              │
     │            deliver to app      │                              │
     │ ─────────────────────────────► │   init(lockData, lockMac)    │
     │                                │ ───────────────────────────► │
     │                                │          unlock()            │
     │                                │ ───────────────────────────► │
     │                                │   ◄── success / failure ──   │

1. Fetch on your server. Call the e-key endpoint with your apikey from your backend — never put the API key in the mobile app.
2. Deliver lockData + lockMac to the app over your own authenticated channel (e.g. your app's session).
3. Initialise the SDK with those two values when the guest is at the door.
4. Call unlock. The SDK performs the Bluetooth handshake and reports success or failure. Surface the result to the guest.

Keep the API key server-side. The mobile app should only ever receive the per-booking lockData/lockMac, fetched and forwarded by your backend. The apikey itself must never ship inside an app binary — see Security.

Operating requirements

For a Bluetooth unlock to succeed, the guest's device needs:

• Bluetooth enabled and the OS Bluetooth permission granted to your app.
• Physical proximity to the lock (within Bluetooth range — a few metres).
• A reasonably accurate device clock, since credentials are time-bounded.

The SDK reports a clear failure when any of these aren't met; handle those cases in your UI (prompt to enable Bluetooth, move closer, etc.) rather than treating them as hard errors.

When to use which credential

If you only need passcodes, you don't need the SDK at all. Reach for it when you want the phone-as-key experience inside your own app.