Vendors
Every vendor implements the same normalized device/access-code shape. Real vendor quirks are absorbed at the adapter layer — never exposed as vendor-specific fields you have to branch on.
Nuki Live
- Listing devices, checking device readiness, and creating/revoking keypad access codes are live-verified against real hardware, including a Nuki Opener (building/street-door intercom, not just the unit lock).
- A device only supports keypad codes if it has a physical Nuki Keypad paired — devices without one report
0available access-code slots (capabilities.maxAccessCodes). - Remote unlock (
capabilities.remoteUnlock) is live-verified — it works independently of keypad pairing, on any smart lock. Nuki's own team confirms their unlock command can report success even when the physical unlock silently fails — lockapi checks the lock's actual state afterward and returnsUNCERTAINrather than a falseCONFIRMEDin that case. See Remote unlock. - Remote lock (
capabilities.remoteLock) uses the same command shape as remote unlock, but hasn't been separately exercised against real hardware yet — treat as implemented-but-unverified for now. - Openers/intercoms (
remoteUnlock: true,remoteLock: false, no keypad codes) open the electric strike on unlock; there's no bolt position to lock. Nuki natively recognizes Fermax/Comelit/Golmar intercoms — the three most common brands in Spanish apartment buildings. - Account linking is self-serve today via a personal API token (no OAuth redirect needed) — see the in-product guide on the connect page. A true OAuth redirect flow and inbound webhooks both still need Nuki's manual "Advanced API Integration" approval, pending with no ETA.
TTLock In progress
- Gateway-mediated: a command can be accepted by the API before it reaches the physical lock.
- Remote unlock additionally requires the tenant's own TTLock account to have "remote unlock" explicitly enabled per-lock — a real per-device gate, not just a gateway-online check.
- Account linking collects your TTLock username and password directly (no OAuth redirect — TTLock's "OAuth2" is a resource-owner-password grant, not a consent-page flow).
- Access-code creation and remote unlock are implemented against TTLock's published API docs but not yet exercised against a live lock and gateway.
Akiles In progress
- Professionally-installed access control (cylinders, controllers, pinpads) — the enterprise/hospitality segment rather than a DIY-retrofit lock.
- Real OAuth connect flow. Access-code creation, listing, and revocation are implemented against Akiles' published API docs but not yet exercised against a live org.
- Inbound webhooks are stubbed — the signing mechanism isn't documented anywhere reachable yet.
Tedee In progress
- Real OAuth2 (Code + PKCE + Secret) connect flow, implemented against Tedee's live OpenAPI spec.
- Supports Tedee Gate — a relay module for shared building/gate doors, the same "building entry, not just the unit door" category as Nuki Opener. Gates have no keypad-code support (
supportsPin: false) and no reportable open/closed state, so unlock attempts always returnUNCERTAIN. - Access-code creation and remote unlock are implemented but not yet exercised against a live lock.
Yale / August In progress
- Built against the same unofficial cloud API the Yale/August mobile app itself uses — there is no self-serve official developer API for Yale/August today. Account linking collects your email + password, then emails a one-time verification code to confirm (
password_2fa). - Remote unlock only — no endpoint in this API creates or revokes a keypad PIN, so Yale devices always report
supportsPin: false,maxAccessCodes: 0. UsedeliveryMethod: "REMOTE"for Yale. - Not yet exercised against a real account/lock.
Tuya In progress
- No multi-tenant OAuth exists for Tuya without shipping a native app, so Tuya devices connect differently from every other vendor: you share an individual lock from your own Tuya app to a lockapi- owned account, then pick it from a device list on the connect page. Tenant isolation happens at the device level, not the account level.
- Access-code creation, listing, and revocation are implemented but not yet exercised against a live lock.
Building-entry devices
In Spain especially, guest friction is often at the building's street door, not the apartment door. Nuki Opener and Tedee Gate both model this as a normal Device with remoteUnlock: true — no separate API surface. These devices never support keypad codes and never support remote lock (electric strikes have no bolt to lock).
Test mode (all vendors)
Any sk_test_... key is routed to a simulated lock provider regardless of which vendor a connected account claims — 2-3 deterministic fake devices, instant connect, no physical hardware required. This is the fastest way to build and test your integration end to end.