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 0 available 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 returns UNCERTAIN rather than a false CONFIRMED in 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 return UNCERTAIN.
  • 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. Use deliveryMethod: "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.