If you are an advanced user you can integrate the LOQED Touch Smart Lock with other products and services via a one of our three APIs. In general, all APIs provide the same functionality. At the end of this article a table is provide with a detailed overview.
Web API
If you are integrating with an application on the web, this is the recommended way. For each lock you have administrator access to, you can choose to create an API key for API access, or not. Find out more about this API here.
Local bridge API
The LOQED Bridge runs a mini-webserver. If you are integrating with an application in your home such as a smart home hub, this is the recommended way. It provides the same functionality as the “normal web API”, except that for any user who opens the door, the name, e-mail address, and key name is not available. However, the local key ID (a unique number for each key inside the lock between 0 and 250) is provided, so you can still identify users. Find out more about this API here.
OAuth 2.0 web API
The OAuth 2.0 API is meant for third party services that only support OAuth 2.0. You can only use the LOQED OAuth 2.0 API after you LOQED has provided you access.
The OAuth 2.0 provides access to all locks at once to which the administrator who is setting up the OAuth connection has access to. Because OAuth 2.0 applications (such as Google Home) in general cannot do any signature calculations on their servers, inside the OAuth login token, also a ‘decryption key’ is stored. When their system calls the LOQED server, the LOQED server receives this ‘decryption key’ and is able to decrypt all the lock’s keys for the smart locks the OAuth client has access to, generate a digital signature, and change the lock’s state. The LOQED server directly forgets this ‘decryption key’. Contact us if you want to make an OAuth 2.0 integration.
Overview
|
|
|
|
Function | OAuth 2.0 web API | Normal web API | Local API |
API readily available | Only after LOQED’s approval | ||
Use case | Web application | Web application | Local network application |
Control lock, LOQED server generates the signature based on your encryption key | Yes | Yes | Yes |
Control lock, your own application generates the signature and you keep the encryption key (more secure) | No (applications such as Google Home do not support it) | Yes | Yes |
Get status (lock state, battery, and more) | Yes | Yes, limited to few requests per day | Yes |
Webhook call-back when lock state is reached | Yes | Yes | Yes |
Webhook call-back when going to a lock state (not reached if motor stalls for example) | No | Yes | Yes |
Webhook call-back for battery percentage | No | Yes | Yes |
Webhook call-back when lock loses BLE connection to bridge for > 15 seconds | No, but status can be requested at status endpoint. | No | Yes |
Webhook call-back provides user data such as e-mail address and key name | Yes | Yes | No (only numeric key ID) |
Security
|
|
|
Method | Security | Description |
OAuth 2.0 API | Good | Your lock’s encryption key is used by LOQED server to generate the signature, but not saved. |
Web API, LOQED server signs the command with the encryption key you provided | Good | Your lock’s encryption key is used by LOQED server to generate the signature, but not saved. |
Web API, you sign the command yourself | High | The signed command you sent is only valid for 15 seconds. |
Bridge API, bridge signs the command with the encryption key you provided | Low | Your encryption key is sent over an unsecure HTTP connection to the bridge. Other persons on your local network could potentially retrieve the encryption key. |
Bridge API, you sign the command yourself | High | The signed command you sent is only valid for 15 seconds. |
Tips
When the lock is offline (e.g. no internet connection, no bridge to lock communication, empty batteries), the lock state and battery level become unknown. Ensure your application is able to handle this.