Skip to main content
All CollectionsIntegrations
LOQED available APIs
LOQED available APIs
Updated over a year ago

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.

Did this answer your question?