.png)
Kandji Integration Guide
Integrate Kandji with enterprise systems through its REST API, selected webhook-style notifications, and Martini workflows for device data, compliance, and lifecycle automation.
Kandji integration options at a glance
Kandji is primarily integrated through its REST API, which provides programmatic access to Devices, Users, Blueprints, Library Items, Applications, and documented device-management operations. Martini can authenticate with a Kandji Bearer API token stored in secrets, retrieve paginated JSON responses, transform the data, apply business rules, and synchronize results with downstream platforms. Kandji also provides webhook-style notifications for selected event types in some tenant configurations; Martini can receive those requests through an API endpoint and process them asynchronously. General-purpose GraphQL, SOAP, file, database, and bulk or asynchronous APIs were not confirmed, so integrations should use documented REST endpoints with controlled iteration and periodic reconciliation.
| Integration point | Supported by Kandji? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Kandji's primary integration mechanism for Devices, Users, Blueprints, Library Items, Applications, and documented management operations. | Martini can consume Kandji REST endpoints, send Bearer authentication, parse JSON, paginate through results, transform fields, and expose normalized APIs to downstream systems. |
| Webhooks / outbound callbacks | Limited | Kandji webhook-style notifications may be available for selected event types in some products or tenant configurations. | Martini can receive supported notifications through an API endpoint or webhook workflow, validate and deduplicate the request, and process longer work asynchronously. Coverage must be verified per tenant. |
| Authentication | Yes | Kandji uses API tokens supplied as Bearer tokens in the HTTP Authorization header. | Martini can store the token in secrets management and attach it to requests without embedding credentials in workflows, mappings, or logs. |
| Bulk / async / batch APIs | Not confirmed | Some device actions may affect multiple devices, but a general-purpose bulk or asynchronous job API was not confirmed. | Martini can use controlled iteration, bounded concurrency, checkpoints, and workflow retries when endpoint-specific documentation supports the operation. |
| GraphQL APIs | Not confirmed | No official Kandji GraphQL API was confirmed in the supplied research. | Martini can consume GraphQL APIs generally, but Kandji integrations should use the confirmed REST API unless Kandji documents GraphQL availability. |
| SOAP APIs | No | No official Kandji SOAP API was identified. | Martini can consume SOAP services generally, but SOAP is not an applicable Kandji integration mechanism based on the supplied research. |
| File / attachment APIs | Not confirmed | A general-purpose Kandji file or attachment API was not confirmed; structured device-management data should be exchanged through REST. | Martini can process files from other systems when needed, but should not assume Kandji file exchange without endpoint-specific documentation. |
| Database / analytics access | No | Direct database access to Kandji-managed data is not confirmed; integrations should use Kandji's API. | Martini can connect to target databases for reporting or synchronization, while keeping Kandji access API-led. |
How Kandji exposes data and business events
Kandji REST APIs
Kandji's REST API is the primary confirmed integration mechanism for retrieving device-management data and invoking documented administrative operations. It covers resources such as Devices, Users, Blueprints, Library Items, and Applications, with exact fields and endpoint availability dependent on API version and tenant configuration.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates with a Kandji Bearer API token from secrets, calls the required REST endpoint, follows documented pagination, parses JSON, applies validation and business rules, and writes the result to a target system or returns it through a Martini API.
Implementation sequence
Kandji Webhook Notifications
Kandji provides webhook-style notifications for selected event types in some product and tenant configurations. Coverage, payload structure, request authentication, signing, and retry behavior must be verified before relying on a specific event.
Martini implementation pattern
Martini implementation pattern: expose a controlled Martini API endpoint, accept only supported Kandji notifications, validate the request and event type, acknowledge quickly, and process the payload asynchronously. Periodic REST polling remains the reconciliation path for state changes without webhook coverage.
Implementation sequence
Kandji Authentication
Kandji's documented primary authentication pattern uses an API token in the HTTP Authorization header as a Bearer token. OAuth 2.0 and separately configured JWT authentication were not confirmed as standard Kandji public API methods.
Martini implementation pattern
Martini implementation pattern: store the Kandji token as a protected secret, reference it from REST API configuration, restrict access to the minimum required permissions, and ensure credentials are excluded from logs and downstream payloads.
Implementation sequence
Common Kandji integration patterns
Pattern 1: Synchronize Kandji devices with ServiceNow
When to use this pattern
Use this pattern when ServiceNow needs an authoritative or near-current view of Apple device inventory, ownership, enrollment, and selected compliance attributes. A scheduled workflow is appropriate when complete inventory reconciliation is more important than immediate event processing.
Integration direction
Example Mapping
| Kandji Field | Canonical Field | Target Field |
|---|---|---|
| device_id | externalDeviceId | u_kandji_device_id |
| serial_number | serialNumber | serial_number |
| device_name | deviceName | name |
| assigned_user | assignedUser | assigned_to |
Martini implementation pattern
A scheduler starts the workflow, which retrieves all Device pages, normalizes fields, enriches user or Blueprint references where needed, and applies an upsert keyed by the Kandji device identifier. Invalid records are quarantined, transient failures are retried with backoff, and the last successful page or run checkpoint is recorded.
Martini capabilities used
- scheduled workflows
- API consumption
- pagination orchestration
- data mapping
- business rules
- error handling
Pattern 2: Escalate Kandji compliance exceptions to Jira
When to use this pattern
Use this pattern when outdated operating systems, missing security controls, enrollment problems, or other device conditions should create or update operational and security work in Jira. It prevents duplicate issues when the same device remains non-compliant across multiple runs.
Integration direction
Example Mapping
| Kandji Field | Canonical Field | Target Field |
|---|---|---|
| device_id | deviceKey | customfield_kandji_device |
| operating_system_version | osVersion | description |
| compliance_status | complianceState | priority |
| device_name | deviceName | summary |
Martini implementation pattern
Martini retrieves Devices and applicable state fields, evaluates thresholds and allowlists, and derives a deterministic issue key from the Kandji device identifier and exception type. The workflow creates or updates Jira issues, marks resolved conditions appropriately, and routes authorization, rate-limit, and validation failures to retry or review paths.
Martini capabilities used
- workflow orchestration
- JSON transformation
- business rules
- idempotent upserts
- API consumption
- retry handling
Pattern 3: Process selected Kandji event notifications
When to use this pattern
Use this pattern when the Kandji tenant supports a required webhook event and downstream teams need faster notification of enrollment, device, or management changes. It should be combined with periodic reconciliation because webhook coverage is not confirmed for every Kandji state transition.
Integration direction
Example Mapping
| Kandji Field | Canonical Field | Target Field |
|---|---|---|
| event_type | eventType | notificationTitle |
| device_id | deviceId | metadata.deviceId |
| device_name | deviceName | message |
| occurred_at | eventTime | metadata.occurredAt |
Martini implementation pattern
A Martini API receives the supported Kandji notification, validates its structure and authentication, deduplicates it, and acknowledges quickly. An asynchronous workflow retrieves current resource details when necessary, applies routing and redaction rules, and sends a structured Slack notification. Failed delivery is retried without replaying the device event indefinitely.
Martini capabilities used
- API exposure
- webhook consumption
- asynchronous workflows
- payload validation
- data mapping
- error handling
Pattern 4: Coordinate identity and device lifecycle changes
When to use this pattern
Use this pattern when Okta, Microsoft Entra ID, or another approved identity source must coordinate user and device lifecycle processes with Kandji. Destructive operations such as lock or wipe require explicit approvals, target validation, and audit controls.
Integration direction
Example Mapping
| Kandji Field | Canonical Field | Target Field |
|---|---|---|
| user.id | identityId | Kandji user identifier |
| user.status | lifecycleState | workflow decision |
| device.id | deviceId | Kandji device_id |
| action | approvedDeviceAction | Kandji action endpoint |
Martini implementation pattern
Martini receives or polls identity changes, resolves the associated Kandji User or Device, checks environment-specific rules and permissions, and invokes only documented Kandji endpoints. The workflow records an audit event, uses an application-level request key where possible, and routes ambiguous matches or destructive actions for approval rather than retrying automatically.
Martini capabilities used
- API consumption
- workflow orchestration
- identity mapping
- validation
- business rules
- audit and error handling
Applications commonly integrated with Kandji
Kandji can be integrated with adjacent identity, service-management, collaboration, and endpoint-management products through their respective APIs. Martini provides the orchestration, transformation, validation, and operational controls between these systems; these are implementation patterns rather than claims of turnkey Kandji integrations.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Okta | Coordinate workforce identity, user lifecycle, device context, and access-control processes. | Okta → Martini → Kandji | Use Okta lifecycle or directory data as workflow input, validate user and device relationships, and call documented Kandji endpoints for permitted updates or actions. A reverse workflow can publish selected Kandji inventory or status data to Okta-related processes. |
| Microsoft Entra ID | Connect user and group lifecycle changes with Apple device-management and compliance workflows. | Microsoft Entra ID → Martini → Kandji | Receive or schedule Entra ID changes, map users and groups to Kandji identifiers, apply allowlists and authorization rules, and invoke documented Kandji REST operations. Use reconciliation to detect state drift. |
| Google Workspace | Reconcile managed users and organizational data with Kandji device ownership and enrollment information. | Google Workspace → Martini → Kandji | Retrieve directory data from Google Workspace, normalize identity keys, match them to Kandji Users or Devices, and write only permitted changes. Store external identifiers to make retries idempotent. |
| ServiceNow | Maintain service-management or configuration views of Apple devices and create incidents for compliance exceptions. | Kandji → Martini → ServiceNow | Run a scheduled Kandji inventory workflow, follow pagination, map device identifiers and state fields to ServiceNow records, and upsert using the Kandji device identifier. Route compliance exceptions to incident workflows. |
| Jira | Create operational or security tickets for device-management exceptions and update them as device state changes. | Kandji → Martini → Jira | Evaluate Kandji Devices and application or compliance fields against business rules, create or update Jira issues using a deterministic external key, and close or annotate issues when the condition is resolved. |
| Slack | Notify IT and security teams about enrollment failures, compliance exceptions, or high-impact device actions. | Kandji → Martini → Slack | Use scheduled polling or supported Kandji webhook events to start a workflow, filter actionable conditions, redact sensitive fields, and publish structured notifications through Slack's documented API. |
| Microsoft Intune | Coordinate endpoint-management information where an organization operates mixed Apple and Windows management estates. | Kandji → Martini → Microsoft Intune | Define ownership boundaries, retrieve selected Kandji and Intune objects, normalize device identifiers and status values, and exchange only approved fields through separate workflows with conflict handling. |
| Jamf Pro | Reconcile or consolidate Apple device-management information during migration, coexistence, or multi-tenant operations. | Kandji → Martini → Jamf Pro | Use API-led extraction from each platform, map platform-specific device and policy fields to a canonical model, detect duplicates by serial number or approved identifiers, and route exceptions for review. |
How to build a Kandji integration in Martini
Objective
Establish a secure API relationship with Kandji and the required target systems.
Instructions in Martini
- Create a Kandji API token with the minimum required permissions.
- Store the token in Martini secrets management.
- Configure HTTPS REST requests with the Bearer Authorization header.
- Define target-system credentials and environment-specific configuration separately.
Objective
Select a trigger that matches the required freshness and Kandji event coverage.
Instructions in Martini
- Use a scheduler for inventory reconciliation and periodic state checks.
- Use a protected Martini API endpoint for supported Kandji webhook-style notifications.
- Keep polling or scheduled reconciliation for events that Kandji does not notify.
Objective
Obtain complete Kandji resources reliably from documented endpoints.
Instructions in Martini
- Call the required Kandji REST endpoint.
- Follow pagination until no additional pages remain.
- Preserve stable paging parameters during a synchronization run.
- Record a checkpoint or last successful page where practical.
Objective
Build the Martini workflow that coordinates retrieval, enrichment, decisions, and delivery.
Instructions in Martini
- Separate event intake from longer asynchronous processing.
- Retrieve related Users, Blueprints, or Library Items only when required.
- Bound concurrency for large device inventories.
- Route malformed payloads and authorization failures to controlled error paths.
Objective
Convert Kandji JSON resources into stable canonical and target-system models.
Instructions in Martini
- Map stable Kandji identifiers to external keys.
- Treat optional fields as nullable and preserve useful unknown fields.
- Normalize device, user, Blueprint, application, and status values.
- Avoid using display names as unique identifiers.
Objective
Enforce operational, compliance, and safety decisions before writing or acting.
Instructions in Martini
- Evaluate operating-system, enrollment, security, and ownership conditions.
- Prevent duplicate tickets and notifications with deterministic keys.
- Require explicit allowlists or approvals for lock, wipe, restart, and similar actions.
- Redact tokens and unnecessary sensitive data from logs and notifications.
Common Kandji data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Devices | Represent managed Macs, iPhones, iPads, Apple TVs, and other enrolled Apple devices, including inventory, enrollment, ownership, and state information. | ServiceNow, Jira, reporting databases, Microsoft Intune, Jamf Pro | Martini retrieves paginated resources, preserves stable Kandji identifiers, maps inventory and status fields, applies compliance rules, and performs idempotent upserts. |
| Users | Represent people associated with managed devices and Kandji administration. | Okta, Microsoft Entra ID, Google Workspace, ServiceNow | Martini normalizes identity attributes, matches users to external directory identifiers, handles nullable fields, and coordinates approved lifecycle changes. |
| Blueprints | Represent policy and configuration assignments used to manage device groups. | ServiceNow, reporting platforms, Jamf Pro, audit systems | Martini maps Blueprint identifiers and assignment data to canonical policy models and tracks changes without treating display names as unique keys. |
| Library Items | Represent configuration, application, security, and management items assigned through Blueprints. | Reporting platforms, ServiceNow, audit systems | Martini retrieves documented fields, relates items to Blueprints and Devices where available, and routes policy exceptions for review. |
| Applications | Represent applications deployed to or inventoried on managed devices. | ServiceNow, security reporting, asset databases, Jira | Martini normalizes application and device relationships, evaluates approved business rules, and synchronizes selected inventory attributes. |
| Device actions | Represent operational actions such as locking, wiping, restarting, or updating device state where supported by the relevant endpoint. | Kandji, ServiceNow, Jira, audit systems | Martini validates target identifiers, enforces explicit allowlists and approvals, sends documented actions, records outcomes, and prevents unsafe duplicate retries. |
Authentication and security considerations
Bearer token authentication
Kandji's primary documented API authentication method is an API token sent as a Bearer token in the HTTPS Authorization header. OAuth 2.0 and separately configured JWT authentication were not confirmed as standard Kandji public API methods.
Credential protection
- Store Kandji API tokens in Martini secrets management.
- Grant only the permissions required by each workflow.
- Do not place tokens in workflow payloads, mappings, error responses, or logs.
- Restrict Martini API endpoints that receive Kandji notifications and validate available request authentication or signing information.
Operational considerations for Kandji integrations
Reliability controls
- Treat list endpoints as paginated unless endpoint documentation states otherwise.
- Handle HTTP 429 responses with bounded backoff, jitter, and controlled concurrency.
- Use stable Kandji identifiers for idempotent upserts and webhook deduplication.
- Use periodic reconciliation because webhook coverage may be limited to selected events.
- Do not assume timestamp filters, bulk jobs, or asynchronous APIs unless documented for the endpoint.
Schema and action safety
- Treat optional fields as nullable and version mappings as Kandji API behavior changes.
- Test changes to Devices, Blueprints, Library Items, status values, and device types.
- Protect lock, wipe, restart, and other impactful actions with allowlists, approvals, target validation, and audit logging.
- Monitor 401, 403, 404, 409, 429, 5xx, malformed payload, and downstream delivery failures.
Why use Martini instead of scripts or point-to-point integrations?
Centralized orchestration
Martini separates Kandji API access from downstream application logic, allowing one workflow to retrieve device data, apply policy decisions, transform payloads, and coordinate multiple targets without duplicating integration code.
Maintainable integration assets
Workflows, APIs, mappings, secrets, validation rules, and error paths can be maintained as reusable integration assets. This is more adaptable than isolated scripts when Kandji fields, target schemas, or business rules change.
Operational control
- Use scheduled and event-driven processing together for reconciliation and timely notifications.
- Apply consistent pagination, retries, idempotency, validation, and audit controls.
- Expose a controlled Martini API façade when downstream applications should not access Kandji directly.
- Keep credentials and environment-specific settings outside workflow logic.
Frequently asked questions
Kandji is primarily integrated through its REST API using Bearer API-token authentication. Enterprise workflows can retrieve Devices, Users, Blueprints, Library Items, Applications, and documented device-management operations, then synchronize or act on that data in other systems. Kandji webhook-style notifications may also be available for selected events in some tenant configurations.
Yes. Martini can consume Kandji's REST API, authenticate with a protected Bearer token, transform Kandji JSON, apply business rules, and send results to other applications. Where supported by the Kandji tenant, Martini can also receive webhook-style notifications through a controlled API endpoint.
No. A dedicated Kandji connector is not required. Martini can integrate with Kandji using its confirmed native REST API and, where enabled and documented, selected webhook-style notifications and standard HTTP authentication.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Kandji. The integration is subject to the provisioned capacity of the Martini environment. Kandji, cloud infrastructure, and other third-party services may charge separately according to their subscription, usage, and deployment models.
REST is the primary confirmed method for new Kandji integrations. Selected webhook-style notifications can support event-driven processing where the tenant exposes the required event, while scheduled REST polling remains important for reconciliation. GraphQL and SOAP were not confirmed for Kandji, and a general file, database, or bulk API was not confirmed.
Potentially, for event types supported by the Kandji tenant's webhook functionality. Coverage should be verified for the required event, including payload, authentication, and retry behavior. Martini can receive the notification through an API endpoint, process it asynchronously, and use REST polling to reconcile state changes not covered by webhooks.
A scheduled Martini workflow can retrieve paginated Kandji resources, compare them with stored synchronization state, map fields into a canonical model, and upsert target records using stable Kandji identifiers. Timestamp filters should only be used when documented by the specific endpoint; otherwise, full or checkpointed reconciliation may be required.
Martini workflows can distinguish authentication, authorization, missing-resource, conflict, throttling, transient server, and malformed-payload errors. They can apply bounded retries with backoff for transient failures, use deterministic external keys to prevent duplicate writes, deduplicate webhook deliveries, and route unresolved records to operational review.
Related Martini documentation
Kandji APIs
Workflows
Integrate Kandji with Martini
Use Martini to connect Kandji's REST API and supported event notifications with identity, service-management, collaboration, and reporting systems through governed workflows and reusable APIs.