Devices & capabilities

There is one Device resource per physical lock — not per keypad. A keypad (where the vendor supports one) is a paired peripheral of a lock, not a separate resource you address on its own. What a given lock can actually do is exposed on GET /v1/devices as a capabilities object, and that's what decides which access-code delivery method you can use on it.

GET /v1/devices

[
  {
    "id": "dev_123",
    "name": "Front Door",
    "capabilities": {
      "supportsPin": true,
      "maxAccessCodes": 100,
      "remoteUnlock": true,
      "remoteLock": true
    },
    "batteryLevel": 87
  }
]

What each flag means

• supportsPin / maxAccessCodes — whether a physical keypad is paired to this lock, and how many codes it can hold at once. Both are false/0 for a lock with no keypad — you can't create a KEYPAD code on it.
• remoteUnlock — whether this lock supports on-demand unlock commands sent through the vendor's cloud.
• remoteLock — whether this lock supports on-demand lock commands. Always falsefor openers/intercoms (they have no bolt) and any vendor whose API doesn't expose a lock action.

Picking a delivery method

POST /v1/access_codes takes a deliveryMethod: KEYPAD (default) or REMOTE. The API rejects the request with a 400 up front if the target device doesn't have the matching capability — you don't find out from a confusing vendor-specific error after the fact.

• KEYPAD requires supportsPin: true and maxAccessCodes > 0. The code is synced to the lock; the guest types it on the physical keypad. See Connect → devices → codes.
• REMOTE requires remoteUnlock: true. Nothing is synced to the lock at creation time — your own app collects the code from the guest and calls lockapi to verify it and trigger the physical unlock in one step. See Remote unlock.