Sciener smart locks are managed through the TTLock / Sciener app and, for developers, through an open API. Knowing how the app, the cloud and the lock fit together matters whether you are a homeowner with one door or an integrator connecting thousands of locks to a booking system.
Three layers
The platform is built in three layers. At the door sits the lock and, optionally, a gateway — the lock holds credentials and makes authorisation decisions locally, while the gateway bridges it to the internet when remote access is needed. Behind them is the cloud, the backend that stores your account, locks, users and permissions and relays commands and events between app and locks. And in front of them is the app and API — the TTLock / Sciener app as the user interface for managing everything, and the open API exposing the same capabilities to your own software.
What the app does
For most users, the app is all they need. From it you enrol and revoke credentials — fingerprints, passcodes, cards, mobile keys — and generate time-limited passcodes for guests or contractors. You can pull up a full unlock history per lock, receive real-time alerts for an unlock, a low battery or a door left open, and trigger a remote unlock when a gateway is fitted. Locks can be grouped and permissions assigned per user, so a team can share management of a property. The app is available for iOS and Android and supports multiple administrators.
What the API adds
When access control needs to be part of a larger workflow, the open API lets your software do programmatically everything the app can do manually. In hospitality, a PMS or channel manager creates a time-limited passcode when a booking is confirmed and revokes it at check-out. Property-management software enrolls a new tenant's credentials across the relevant doors as part of onboarding. Corporate environments provision and deprovision access from an HR or identity system. And operations and security teams can pull unlock events into a central dashboard of their own. The API exposes locks, users, passcodes, unlock events and remote commands as resources you can read and write.
How a typical integration works
A hospitality integration, for example, follows a simple flow. A booking is created in the PMS. The PMS calls the API to create a time-limited passcode on the relevant lock, valid from check-in to check-out, and sends the code to the guest by email or SMS. The guest enters the code at the door; the lock authorises locally and logs the event. At check-out, the code expires automatically — and the PMS can revoke it sooner if needed.
Because authorisation happens on the lock, the integration does not create a real-time dependency. Even if the PMS or the API is briefly unavailable, the guest's code still works.
App, API, or both
For a few doors under hands-on management, the app is all you need. For many doors, or for credentials tied to bookings and tenancy, the API pays for itself by automating the credential lifecycle. Most integrations end up mixed: the app for day-to-day work, the API for the high-volume, repetitive workflows.
If you are an end user, install the TTLock / Sciener app and follow the pairing flow in the installation guide. If you are evaluating the platform as an integrator, contact Sciener for API documentation and credentials; the product range lists every device in the ecosystem.