I am working on a plugin for an online shop (which is in this case an online booking system) to provide the automation for checkin/out control using Nuki infrastructure. I have read what I found on the topic of short term rentals and it does not fit my use case for the API. My use case is:
The company operates multiple rooms which are being rented for short time.
A client books a property for some time period and receives the entrance PIN per Email.
User actions on the lock should be logged and users should be identified uniquely.
The PINs should be disabled after the rent period is over.
I have looked into the Nuki Web API and my plan is the following:
After a client books a property, the system issues an API PUT request to /smartlock/{smartlockId}/auth, adding a PIN. As far as I see the request can include 2 points in time between which the PIN will be active.
Then the system send the PIN with the order confirmation email to the client.
The logging functionality is built in into the Nuki Lock + Nuki Bridge + Nuki Web combination and and can be accessed using Nuki Web. Can I associate the PINs with Accounts, SubAccounts or Users? I can not imply that using the API documentation alone, it seems to me that /smartlock/{smartlockId}/auth works independently from /account/user, /account as well as from /account/sub.
The PIN is automatically disabled after the time period specified in 1 is over, the client can not access the property again.
If I cannot associate PINS with Accounts, SubAccounts or Users, I would provide unique identification inside the online booking system associating the smart lock authentication name with the system user who rented the according time period.
Is this concept viable? I mean, can I really implement it with the Nuki Web API for production use or did I miss something important? Can I associate the PINs with Accounts, SubAccounts or Users?
One further question: Is Nuki Bridge capable on issuing programmable HTTP or MQTT (or something similar) requests on other devices in the local network where it is installed?
I would be very grateful if someone could help me!
Roman
This is correct if I assume you are using a Nuki Keypad in the setup and talk about a Keypad entry code.
When not using a Keypad (using type=13 for the endpoint) you would trigger an invite code through the endpoint (using type=0).
Regarding
You can assign any authorization to an accountUser via the API. In case of a Keypad entry code we do not do this in Nuki Web as an entry code can be more easily shared and is often not assignable to a single person.
For tracking reasons alone the best way would be to store the unique ID of the authorization and collect the usage data from the activity logs (GET /smartlock/{smartlockId}/log or via the new webhooks we currently have in Beta)
If you set the start- and end-dates in 1 the access will no loger be granted for an authorization after end-date/time is reached. Still you would have to remove the authorization from the device (DELETE /smartlock/{smartlockId}/auth/{id}) to make sure authorization-storage is not running full.
if I assume you are using a Nuki Keypad in the setup
I think this is exactly what we’ll be doing.
Regarding the “GET /smartlock/{smartlockId}/log”… This endpoint has a parameter named “authId”, thich, I guess is the uniqueID of the authorization that you mention. Where do I get it? Does the “PUT /smartlock/auth” return it in response?
Currently you have to get the ID back yourself after creating a new authorization.
As far as I see, I can get the AuthID by querying “GET /smartlock/{smartlockId}/auth” and taking the one with the name I specified during creation, right? Or what is a better way?
@rreimche Yes, that is currently the best approach.
You best store id and authId from that request as you will need the first one to later change or delete it (POST /smartlock/{smartlockId}/auth/{id} or DELETE /smartlock/{smartlockId}/auth/{id}) and the second one for the activity logs as described by you.