Kisi API and mobile SDKs
Identify the Kisi resources and permissions needed by the application. Handle account changes, event delivery and physical controls as separate operations.
Sources and scopeSource record 25 August 2026
Technical source record: 25 August 2026. Check the linked documentation for current product requirements.
Inherited check dated 10 September 2026. Supporting evidence for this inherited check has not been independently confirmed.
Recorded scope: The API overview, canonical reference address, request limits and overall versioning policy were checked. Key expiry details, SDK behaviour and tenant entitlements require the linked product documentation.
Public Kisi product and OpenAPI documentation reviewed on 25 August 2026; organization plans, sandbox/production approval, mobile SDK partner ID, exact hardware/firmware, endpoint schemas, custom quotas, and marketplace terms require Kisi confirmation.
On this page
Overview#
Vendor APIs / Access and identity / Kisi
Kisi publishes a JSON/HTTPS API for organizations, users, locks, access rights, events and unlock workflows, plus webhooks and mobile SDKs for embedded access. The REST API can support user provisioning and cloud unlocks; the iOS/Android SDKs add supported proximity/tap behaviour and require separate partner access and hardware.
Documented interface map#
| Surface | Publicly documented purpose | Access boundary |
|---|---|---|
| Kisi API | Organization, user, place, lock, access, event and command resources | Public OpenAPI reference; organization account/API key and permissions required |
| Webhooks | Real time event delivery to an integration | Receiver authenticity, retry and reconciliation must follow current guide |
| Mobile SDK for iOS/Android | Embeds Tap to Unlock, in app unlock and MotionSense workflows | Partner ID/SDK access, provisioned users and compatible controller/reader required |
| Marketplace application | Admin configured integration inside Kisi dashboard | Partner approval and marketplace quality/security requirements |
| Sandbox and hardware dev kit | Authorised development environment | Requested through integration partner onboarding; not production entitlement |
Authentication and key lifecycle#
Most API calls use a Kisi API key/login secret in the documented authorisation scheme over HTTPS. Organization owners or administrators can create keys. The current guide recommends a separate API key for each integration instance and says:
- a user can hold up to 40 API keys, after which older keys expire;
- keys expire after six months of inactivity by default unless created under the documented non expiring option;
- organization owner creation can avoid an administrator departure invalidating the integration.
A non expiring secret increases risk; prefer bounded lifecycle and rotation unless an approved operational requirement says otherwise. Keep keys in a backend secret store, never in browser/mobile source, and include the integration identification/contact headers required of partners. Revoke on decommission or compromise.
User attribution and identity#
An administrator key used directly for every unlock can attribute events to the administrator rather than the actual person. Kisi documents user provisioning and user specific login/secret patterns for applications that require individual audit. Apply them only through the current guide and protect every user secret like a credential.
Use stable user identifiers and explicit organization/place scope. Define joiner/mover/leaver behaviour, group/access changes, schedule timezone and credential revocation. Don't create “managed” users or non expiring device logins without retention and deletion policy.
Limits, versioning, and deprecation#
Kisi's API overview, updated 1 September 2026, documents 5 requests per second per user for authenticated calls and 5 per second per IP address for unauthenticated calls. Some endpoints have custom limits. Limits are mutable. Serialize/bound work per user, add exponential backoff for HTTP 429 and read each endpoint’s custom rule.
Kisi says the API has no overall versioning scheme and aims to preserve compatibility. The OpenAPI document’s 1.0.0 label is a specification document version, not evidence of a /v1 lifecycle. When incompatibility is necessary, Kisi documents Deprecation and Sunset response headers. Capture and alert on both headers and subscribe to the developer newsletter.
Use endpoint specific pagination/filter fields from the OpenAPI schema. Don't assume all collections fit a response or share one cursor/offset model.
Webhooks and events#
Authenticate webhook delivery using the current Kisi mechanism, validate freshness, deduplicate, enqueue durably before acknowledgement and reconcile after gaps. Preserve event ID, source time, ingest time, organization/place/lock and attributed user while minimizing names and credential material.
An unlock event, lock output state, door contact state and confirmed passage are different facts. The API can't replace supervised door hardware or local life safety logic.
Mobile SDK boundary#
Kisi documents Tap to Unlock using BLE on iOS or NFC on Android, in app cloud unlock, and MotionSense for supported hardware. The SDK handles proximity proof/reader interaction; the host app remains responsible for user lifecycle, UI, secure credential storage, authorisation and privacy.
Request a partner ID and follow the supplied testing protocol. Pin SDK, mobile OS, controller/reader, firmware and network/offline behaviour. Never reverse engineer proximity advertisements or extract user secrets from the SDK.
High impact safety boundary#
Door/elevator lockdown and unlock are high impact. Allowlist targets, require explicit application authorisation, record requester/reason, and handle timeout as uncertain. Don't expose a generic “call any Kisi endpoint” proxy.
Primary sources#
- Kisi API overview, capability, rate limit and versioning policy.
- Kisi OpenAPI reference, public operation, error, custom limit and deprecation contract.
- How to integrate Kisi and getting started, sandbox, keys, hardware and SDK access.
- Generate an API key, administrator, key count and inactivity lifecycle.
- Integration methods, user provisioning, user attributed unlock, SDK and marketplace boundaries.
- Mobile SDK integration process, platform/hardware and partner ID requirements.