Kandji — Integration Setup
Prerequisites
- A Kandji tenant with devices enrolled
- A Kandji account with permission to manage API tokens (Owner or Admin)
- CMDash Essentials tier or above
Step 1: Create an API token
- Log in to the Kandji web app.
- Go to Settings → Access → API Token.
- Click Add Token.
- Name it
CMDash. - Under permissions, enable exactly:
- Device list (
GET /api/v1/devices)
- Device list (
- Click Create Token and copy it immediately — the token is shown once and cannot be retrieved later.
Least privilege: CMDash only issues
GETrequests to the device list. Do not enable device actions, lock, erase, or library-item permissions — nothing in this integration can use them, and a token that can erase a Mac is a materially different risk to hold.
Step 2: Find your API subdomain
Your Kandji API host is not the same as your web console URL.
- On the same Settings → Access page, note the API URL, which looks like
https://acme.api.kandji.io. - The subdomain is the first segment —
acmein this example.
Step 3: Connect in CMDash
- Navigate to Integrations in your CMDash dashboard.
- Find Kandji and click Connect.
- Enter:
- Subdomain — the first segment only. For
https://acme.api.kandji.io, enteracme. - API Token — stored as this connection's access token and sent as
Authorization: Bearer <token>.
- Subdomain — the first segment only. For
- Click Save & Test Connection.
What Syncs
| Data Type | Kandji API | Behaviour on failure |
|---|---|---|
| Device inventory — name, platform, OS version, FileVault state, agent connectivity, lost-device status, last check-in | GET /api/v1/devices | Fails the sync — this is the only dataset |
How the numbers are computed
- Managed coverage counts devices with the Kandji agent installed and not flagged as missing. A laptop reported lost is not reporting in, whatever the agent flag says, so it does not count toward managed coverage.
- Disk encryption reads Kandji's FileVault status. FileVault is macOS-only — Kandji omits the field entirely for iPhones, iPads and Apple TVs, and those devices are recorded as unknown rather than unencrypted, and excluded from both sides of the encryption-coverage percentage. An iPad is not "an unencrypted device", it is a device this field does not describe.
- iPhones, iPads and Apple TVs are mapped to OS family
otherrather thanmacos, so a future macOS-specific control cannot silently inherit them into its denominator. - A device that has never checked in is recorded with an epoch
lastSeenAt, never with "now".
Troubleshooting
- 401 Unauthorized: The token was revoked or regenerated. Kandji tokens cannot be retrieved after creation — issue a new one.
- 403 Forbidden: The token exists but lacks the Device list permission. Edit the token's permissions in Settings → Access.
- Connection test fails with a DNS or network error: Check the Subdomain. Enter only the first segment (
acme), not the full URL, and note the API host differs from your web console host. - Device count is lower than the Kandji console shows: Devices flagged as missing are counted as inactive, by design.
- Encryption coverage is computed over fewer devices than your fleet size: intended — only Macs, where FileVault status exists, are in the denominator.
Rate Limits & Sync Behavior
| Setting | Value |
|---|---|
| Sync frequency | Every 4 hours by default (syncInterval is configurable per connection) |
| Pagination | limit/offset, 300 records per page, capped at 5,000 records per sync |
| Rate limit handling | Routed through CMDash's shared token-bucket limiter, which paces requests across the page walk |
| Circuit breaker | Repeated failures open the breaker and the sync is skipped rather than hammering a struggling tenant |
| Failed sync retry | Job queue retries 3 times with exponential backoff (starting at 30s) — see docs/developers/dead-letter.md |
Credential Rotation
Kandji API tokens do not expire. Rotate quarterly.
To rotate:
- In Kandji: Settings → Access → API Token → Add Token. Create the new token before deleting the old one; both work simultaneously.
- In CMDash: Settings → Integrations → Kandji → Edit.
- Enter the new API Token and Save.
- Confirm a successful sync, then delete the old token in Kandji.
Known Limitations
- No per-device deep posture. Kandji's richer blocks (detailed FileVault recovery-key escrow state, per-parameter compliance) live behind a per-device details call, which would be an N+1 over the entire fleet on every sync. CMDash reads the list endpoint only, which already carries everything the normalized endpoint shape can hold.
- No screen-lock or password-policy signal. These are expressed through Kandji Library Items rather than device attributes. CMDash reports nothing rather than inferring a lock policy from an unrelated field.
- No incidents or vulnerabilities. Kandji is a management plane, not a detection product. Claiming those signals would put a checkmark on the catalog page this integration cannot back.
- The 5,000-device ceiling is a truncation, not a sample. Larger fleets are cut off mid-walk, coverage percentages are computed over the truncated set, and the sync log carries a warning.