CHeKT Apps

Third-party access, designed for monitoring.

A clean, scoped, and revocable way for external developers to integrate with CHeKT. Authentication, permissions, webhooks, and security — all in one app.

What is a CHeKT App?

A CHeKT App is the unit of third-party access in the CHeKT platform. A CHeKT App is installed by a dealer admin, granted a set of permissions, and given an API key to act on behalf of the dealer — without being tied to a single human user.

This matters in operations. When a developer or admin leaves the company, an OAuth token tied to that person breaks the integration. An App's key keeps working. The ownership lives with the dealer, not the individual.

Anatomy of an app

Every CHeKT App is composed of four building blocks. You configure each one in the dealer portal at dealer.chekt.com → Settings → CHeKT Apps.

Authentication

Each app has its own API key. Rotate, revoke, and audit independently of any single user.

Authorization

Grant only the permissions your app needs. Scoped access keeps the blast radius small.

Webhooks

Subscribe to the events you want. Signed delivery, retries, and idempotency built in.

Security

Optional IP allow list. Restrict calls to your known infrastructure.

The app lifecycle

From the moment an admin creates an app to the moment your service receives its first event, the lifecycle has six steps. Once your app is installed, the same loop runs forever — your service calls CHeKT, CHeKT calls your service back.

Dealer admindealer.chekt.com
CHeKT platformAPI + Webhooks
Your appthird-party service
  1. 01
    Dealer adminCHeKT platform
    Create appSettings → CHeKT Apps → New app
  2. 02
    Dealer adminCHeKT platform
    Select permissionsPick scopes like devices:read, events:read
  3. 03
    Dealer adminCHeKT platform
    Subscribe to eventsPick which webhooks the app should receive
  4. 04
    CHeKT platformYour app
    Issue API keyStored once — copy to your secret manager
  5. 05
    Your appCHeKT platform
    Call the APIAuthorization: Bearer <key>
  6. 06
    CHeKT platformYour app
    Deliver webhookPOST with HMAC signature
Figure 1. The six-step lifecycle from app creation through ongoing operation.

Permissions

CHeKT permissions are granular and additive. Each permission grants either read or write access to a specific resource family, and the dealer admin sees the exact set requested before installing your app.

Devices

Cameras, bridges, sensors — anything that reports back to CHeKT.

devices:read
Read device metadata, status, firmware, and configuration.
devices:write
Update device configuration, labels, and groupings.

Events & Alarms

The signal stream that drives every monitoring decision.

events:read
Read events and alarm history across the dealer.
events:write
Acknowledge, dispatch, escalate, or close alarms.
snapshots:read
Read image and video snapshots tied to events.

Sites & Partitions

The physical and logical grouping that holds your devices.

sites:read
Read site, partition, and zone data.
sites:write
Arm, disarm, bypass zones, and configure partitions.

Webhook events

Subscribe to the events your app cares about — and only those. CHeKT delivers each event as a signed POST to the webhook URL you registered when creating the app. Below is the full event catalog with the domain-state coloring that you'll see throughout the dealer portal.

alarm.created

An alarm has been triggered at a site.

alarm.acknowledged

An operator acknowledged an alarm.

alarm.dispatched

A guard or responder was dispatched.

alarm.resolved

An alarm was resolved or closed.

device.online

A device came online.

device.offline

A device went offline.

snapshot.created

A new snapshot is available.

verification.requested

A video verification was requested.

partition.armed

A partition was armed.

relay.activated

A hardware relay was triggered.

A working example

Here's the smallest useful app: it subscribes to alarm.created webhooks, fetches the snapshot tied to the alarm, runs it through a vision model, and writes the verdict back to CHeKT.

This is the shape most AI-verification apps take. The only thing that varies between integrations is what the classifier does inside step 4.

server.ts
1// 1) Bootstrap the SDK
2import { Chekt } from "@chekt/sdk";
3const chekt = new Chekt({ apiKey: process.env.CHEKT_API_KEY! });
4
5// 2) Subscribe to alarm.created webhooks
6app.post("/webhooks/chekt", verifySignature, async (req, res) => {
7  if (req.body.type !== "alarm.created") return res.sendStatus(200);
8
9  const alarm = req.body.data;
10
11  // 3) Fetch the snapshot tied to the alarm
12  const snap = await chekt.snapshots.get(alarm.snapshot_id);
13
14  // 4) Run your verification logic
15  const verdict = await vision.classify(snap.url);
16
17  // 5) Write the verdict back
18  await chekt.alarms.annotate(alarm.id, {
19    source: "your-app",
20    verdict: verdict.label,
21    confidence: verdict.confidence,
22  });
23
24  res.sendStatus(200);
25});

CHeKT Apps vs. Platform Linking

CHeKT supports two integration patterns. Picking the right one upfront saves a lot of architectural pain. The short version: direction matters.

CHeKT AppsPlatform Linking
Direction of API callsYour app → CHeKTCHeKT → Your platform
Best forAI services, dashboards, automationsVideo platforms, panel manufacturers
Auth modelAPI Key (today)API Key → OAuth → Assertion Token
API surfacePublic APIPartner API (extended)

See Platform Linking for the platform-scale variant, or the migration guide if you're moving from a two-way integration to one direction.

Next steps