Reference · built on requestConnectorAccess control & video

Kisi

Places, locks, members, groups, cards, and event streams from Kisi, with lock opening, lockdown, and credential actions.

Request accessPricing ↗

About

Kisi is a cloud access control system built around places, locks, controllers, and readers. Its JSON API at api.kisi.io manages members, groups, cards, shares, schedules, elevators, floors, cameras, reports, and integrations, and publishes an OpenAPI specification. An event_webhook integration posts signed events to a URL you choose.

Through Fibric, an operator reads lock and reader events as they happen, checks who holds which card, and proposes a lock opening, a lockdown, or a card deactivation. You approve each one, and a receipt records what changed and why.

This is a reference listing. It documents what Fibric would read from Kisi and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Lock events such as lock.opened, lock.held_open, lock.forced_open, lock.tailgate, and lock.scheduled_unlock_started through the event webhook
  • Reader and controller events including reader.access, reader.tamper, controller.tamper, and controller_wiegand_connection.excessive_pin_attempts
  • Members, groups, group_locks, and shares, plus place.lock_down and place.occupancy_rate_limit_reach
  • Cards and card assignments with activate, deactivate, assign, and deassign history
  • Event sets created with POST /event_sets and paged with a cursor for about 24 hours
  • Presences through GET /presences, and reports and scheduled reports with download links
  • Cameras and per-camera video links through GET /cameras/{id}/video_link

Proposed actions

  • Target capability: propose opening a lock through the Locks unlockLock operation, POST on the lock's id
  • Target capability: propose a lockdown or its cancellation through POST /locks/{id}/lock_down, /places/{id}/lock_down, and the matching cancel_lockdown endpoints
  • Target capability: propose deactivating, reactivating, or deassigning a card through the /cards/{id} action endpoints
  • Target capability: propose adding or removing a member from a group, or creating an event_webhook integration through POST /integrations

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Escalate a forced or held door

    lock.forced_open and lock.held_open events arrive signed on the webhook. The operator matches them to the place and proposes an alert with the camera video link for that lock.

    With Door Held Open, Access Anomaly

  • Retire cards for people who left

    When your directory marks someone inactive, the operator finds their card assignments and proposes deactivation and group removal for approval.

    With Access Offboarding, Badge Hygiene

  • Review tailgate patterns weekly

    lock.tailgate events are counted per lock and hour. The operator proposes which doors to review and drafts the reminder for the teams involved.

    With Tailgate Review

Requirements

  • A Kisi organization and a user account whose role covers the places and locks the operator will read or act on
  • An API key for that user; a user may hold up to 40 keys
  • Accept and Content-Type set to application/json on every request, over HTTPS only
  • For webhooks, a public URL and the signature_key used to check the X-Signature header
  • Integration partners must send X-Kisi-Integration-Identifier and X-Kisi-Integration-Contact headers
Authentication
An API key sent as Authorization: KISI-LOGIN <API_KEY>, created from the dashboard or POST /logins; OAuth 2.0 authorization code at api.kisi.io/oauth/authorize is also defined.

Limits

  • 5 requests per second per user for authenticated calls, shared across all of that user's logins; 429 when exceeded
  • POST /event_sets is limited to 1 per second and POST /signed_upload_urls to 1 per 10 seconds
  • API keys expire after 6 months of inactivity unless created with expire: false through POST /logins
  • Reports cover at most 180 days per interval; the /shares endpoint is deprecated in favor of role-based access rights

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Kisi ↗

Questions and answers

How are Kisi webhooks signed?
An event_webhook integration takes a signature_key. Kisi computes an HMAC-SHA256 over the request body with that key and sends it as X-Signature with the value sha256=<MAC>. Your endpoint recomputes the MAC and responds with 200.
What rate limits apply?
Authenticated requests are limited to 5 per second per user, and the quota is shared across logins for the same user. Unauthenticated requests get 5 per second per IP. POST /event_sets allows 1 per second. Kisi recommends serial requests for a single user.
Is there an endpoint that opens a lock?
Yes. The unlockLock operation, a POST on the lock's id, opens it; the body may carry a context with the user's location and device services for geofence or BLE restricted locks. Lockdown uses POST /locks/{id}/lock_down or /places/{id}/lock_down with matching cancel_lockdown calls.
Ask about Kisi

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Kisi through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy