.png)
Jamf Integration Guide
Connect Jamf Pro device-management data and selected event notifications with enterprise workflows, identity platforms, ITSM tools, and reporting systems.
Jamf integration options at a glance
Jamf Pro primarily integrates through its current REST APIs, which expose computers, mobile devices, users, groups, policies, packages, and other resources using JSON. Martini can consume these APIs for inventory synchronization, management actions, reporting, and orchestration. Jamf Pro also supports webhook-style notifications for selected events, while scheduled workflows remain important for reconciliation and changes without event coverage. OAuth 2.0 client credentials and bearer tokens provide the main authentication model, with access controlled by Jamf Pro roles and privileges. Legacy Classic API endpoints may support existing deployments, and package operations may require binary file transfer.
| Integration point | Supported by Jamf? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Retrieve and update Computers, Mobile Devices, Users, Groups, Policies, Packages, and other Jamf Pro resources; submit supported management commands and read inventory or compliance information. | Martini can consume Jamf Pro REST endpoints, send JSON requests, paginate responses, map payloads, apply business rules, and write results to other systems or databases. |
| Webhooks / outbound callbacks | Limited | Notify an external endpoint about selected Jamf Pro events for lower-latency reactions. | Martini can expose an API or use a webhook workflow trigger to validate, transform, and route Jamf Pro notifications. Scheduled reconciliation should supplement incomplete event coverage. |
| Authentication | Yes | Authenticate API clients using OAuth 2.0 client credentials, bearer tokens, and Jamf Pro roles and privileges. | Martini can keep client credentials and base URLs in protected environment configuration, obtain or refresh tokens, and send bearer tokens to Jamf Pro APIs. |
| Bulk / async / batch APIs | Limited | Submit management commands or operations affecting multiple devices where the relevant Jamf Pro endpoint supports them. | Martini can batch or iterate requests with controlled concurrency, store correlation data, and distinguish command submission from later device execution. |
| File / package operations | Limited | Upload or manage Packages and support software-distribution workflows where the endpoint requires binary transfer. | Martini can orchestrate package metadata, file transfer, deployment calls, and status updates when runtime payload, storage, and timeout requirements are satisfied. |
| Classic API | Legacy | Support existing integrations that depend on Jamf Pro endpoints not yet available in the current API. | Martini can consume documented legacy endpoints where necessary, but new workflows should prefer the current Jamf Pro REST API when the required resource is available. |
| Database / analytics access | Not confirmed | Direct access to the Jamf Pro operational database is not a standard documented integration method; reporting should use APIs or supported export facilities. | Martini can extract Jamf Pro API data into a separate database or analytics platform, but should not assume direct Jamf Pro database connectivity. |
How Jamf exposes data and business events
Jamf Pro REST APIs
Jamf Pro's current REST API is the primary integration mechanism for Computers, Mobile Devices, Users, Groups, Policies, Packages, inventory, management actions, and other supported resources. Requests and responses commonly use JSON, and endpoint availability and permissions vary by Jamf Pro version and API role.
Martini implementation pattern
Martini implementation pattern: a workflow obtains an OAuth bearer token, calls the required Jamf Pro endpoint, follows the endpoint's pagination model, validates and transforms the response, applies business rules, and writes the result to a target system. Reusable workflows can centralize authentication, retries, correlation, and version-aware mappings.
Implementation sequence
Jamf Pro Webhooks
Jamf Pro supports webhook-style notifications for selected events. These notifications can provide lower-latency reactions, but they do not represent complete change coverage for every Jamf Pro resource or field.
Martini implementation pattern
Martini implementation pattern: expose a controlled API or webhook workflow start trigger, validate the incoming notification, resolve the current Jamf Pro resource when necessary, and route the normalized event to downstream processing. A scheduled reconciliation workflow should cover missed events and unsupported changes.
Implementation sequence
Jamf Pro bulk and asynchronous operations
Jamf Pro supports management operations affecting multiple devices for supported resources. A successful request can mean that a command was accepted or queued, while the device may complete the action later or remain offline.
Martini implementation pattern
Martini implementation pattern: validate the target Computers, Mobile Devices, or Groups, submit operations in controlled batches, persist command or correlation identifiers where available, and use a later status-check or reconciliation workflow. Errors are classified separately for submission, queueing, and device execution.
Implementation sequence
Jamf Pro package operations
Jamf Pro supports package and software-distribution operations, including API-supported package management that may involve binary file transfer rather than JSON-only requests. Package upload and deployment are separate stages.
Martini implementation pattern
Martini implementation pattern: receive approved release metadata, validate the package and target Group, transfer the file when runtime limits permit, invoke the relevant Jamf Pro deployment operation, and publish stage-specific status. The workflow should account for file size, temporary storage, timeouts, and partial completion.
Implementation sequence
Common Jamf integration patterns
Pattern 1: Synchronize Jamf Pro devices to ServiceNow
When to use this pattern
Use this pattern when ServiceNow needs current configuration and ownership data for managed Mac and mobile devices. Webhooks can support selected low-latency updates, while scheduled reconciliation provides completeness for events and fields that Jamf Pro does not notify.
Integration direction
Example Mapping
| Jamf Field | Canonical Field | Target Field |
|---|---|---|
| computer.id | device.externalId | Configuration Item external ID |
| computer.serialNumber | device.serialNumber | Serial number |
| computer.operatingSystem.version | device.osVersion | Operating system version |
| computer.userLocation.username | device.assignedUser | Assigned user |
Martini implementation pattern
A scheduled Martini workflow retrieves paginated Computers and Mobile Devices, optionally processes selected webhook notifications, normalizes identifiers, and upserts ServiceNow Configuration Items. It uses serial number or Jamf device ID for idempotency, validates optional inventory fields, applies bounded retries, and records rejected or incomplete records for review.
Martini capabilities used
- scheduled workflows
- API consumption
- data mapping
- business rules
- idempotent upserts
- error handling
Pattern 2: Build a normalized device compliance feed
When to use this pattern
Use this pattern when security, reporting, or identity platforms require a normalized view of Jamf Pro inventory and policy-related conditions. The workflow can flag stale inventory, unsupported operating systems, unapproved assignments, or unexpected Group membership.
Integration direction
Example Mapping
| Jamf Field | Canonical Field | Target Field |
|---|---|---|
| computer.lastInventoryUpdate | compliance.lastSeenAt | last_inventory_at |
| computer.operatingSystem.version | compliance.osVersion | os_version |
| computer.managementStatus | compliance.managementState | management_state |
| group.name | compliance.group | device_group |
Martini implementation pattern
Martini retrieves Computers, Mobile Devices, Groups, and relevant Policies, then transforms them into a canonical compliance model. Validation and business rules classify each device, while a database or reporting API receives idempotent results. Pagination, throttling, and retry controls protect Jamf Pro during large inventory runs.
Martini capabilities used
- scheduled workflows
- API consumption
- data transformation
- validation
- business rules
- database or API writes
Pattern 3: Automate joiner, mover, and leaver actions
When to use this pattern
Use this pattern when Workday, Microsoft Entra ID, or Okta lifecycle changes must drive approved Jamf Pro user or device actions. It is appropriate for controlled onboarding, reassignment, and offboarding processes where auditability and authorization are required.
Integration direction
Example Mapping
| Jamf Field | Canonical Field | Target Field |
|---|---|---|
| worker.workerId | identity.externalId | Jamf Pro User identifier |
| worker.lifecycleStatus | identity.lifecycleState | workflow decision |
| worker.email | identity.email | Jamf Pro User email |
| device.serialNumber | device.serialNumber | Jamf Pro command target |
Martini implementation pattern
Martini receives an approved lifecycle event or polls for changes, resolves the Jamf Pro User and associated devices, validates the requested action against business rules, and invokes a supported Jamf Pro endpoint. It records the submitted command and correlation data, then uses a later workflow to distinguish queued, completed, offline, and failed outcomes.
Martini capabilities used
- event-driven workflows
- API consumption
- identity matching
- authorization rules
- asynchronous orchestration
- audit logging
Pattern 4: Orchestrate Jamf Pro software deployment
When to use this pattern
Use this pattern when Jira, ServiceNow, or an internal release process governs software deployment through Jamf Pro Packages, Policies, and Groups. It separates approval, package transfer, policy submission, and device execution so each stage can be monitored independently.
Integration direction
Example Mapping
| Jamf Field | Canonical Field | Target Field |
|---|---|---|
| issue.key | release.requestId | deployment correlation ID |
| package.fileName | software.packageName | Jamf Pro Package name |
| targetGroup.name | deployment.targetGroup | Jamf Pro Group |
| release.approvalStatus | deployment.approval | workflow gate |
Martini implementation pattern
A Martini workflow validates an approved release request, checks package metadata and target Group, performs a supported binary upload when configured limits allow, and invokes the appropriate Jamf Pro Policy or deployment operation. It returns stage-specific status to the originating system and retries only safe transient failures.
Martini capabilities used
- API consumption
- workflow orchestration
- file handling
- data mapping
- approval rules
- retry and status handling
Applications commonly integrated with Jamf
Jamf Pro can participate in broader device, identity, service-management, release, and workforce workflows. Martini can coordinate these systems through their documented APIs and event mechanisms while keeping Jamf-specific authentication, mapping, reconciliation, and error handling in reusable workflows.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| ServiceNow | Synchronize managed Mac and mobile-device inventory with Configuration Items, incidents, and service requests, and support approved management actions. | Jamf Pro → Martini → ServiceNow | Use scheduled REST API retrieval and selected Jamf webhook notifications to collect Computers, Mobile Devices, and Users. Map stable device identifiers and ownership data to ServiceNow records, apply idempotent upsert rules, and route approved actions back to Jamf Pro. |
| Microsoft Entra ID | Align user identity, device ownership, access decisions, and conditional-access workflows across identity and device-management processes. | Microsoft Entra ID → Martini → Jamf Pro | Receive approved identity or lifecycle changes, resolve the related Jamf Pro User or device, validate authorization, and invoke only the permitted Jamf Pro API operation. Record correlation data and distinguish command acceptance from later device execution. |
| Okta | Coordinate identity lifecycle, device trust, and user-to-device relationships in organizations using Okta and Jamf Pro together. | Okta → Martini → Jamf Pro | Use an event or scheduled trigger to retrieve identity changes, normalize user identifiers, look up Jamf Pro Users or managed devices, and apply controlled management actions. Use retries for transient API failures and reconciliation for delayed device results. |
| Microsoft Intune | Reconcile Apple-device management and compliance information in organizations operating both Jamf Pro and Microsoft endpoint-management products. | Jamf Pro → Martini → Microsoft Intune | Retrieve Jamf Pro Computers, Mobile Devices, Groups, and relevant policy information, transform it into the target compliance model, and submit supported updates or reports to Microsoft endpoints. Apply version-aware mappings because the exact data flow depends on the configured products. |
| Workday | Use worker lifecycle events to support onboarding, device assignment, and offboarding workflows involving Jamf Pro. | Workday → Martini → Jamf Pro | Consume an approved Workday lifecycle event or scheduled change set, resolve the Jamf Pro User and associated devices, enforce business rules, and submit authorized Jamf Pro actions. Persist the request and later status because device commands may be queued. |
| Jira | Link software deployment requests, change records, and operational tasks to Jamf Pro policies, packages, and device groups. | Jira → Martini → Jamf Pro | Receive a Jira request, validate package and target-group metadata, call Jamf Pro APIs for Packages, Policies, or Groups, and return submission and execution status to Jira. Separate package upload, policy activation, and device completion as distinct workflow stages. |
| Slack | Publish deployment, compliance, or device-management notifications to operational channels without exposing Jamf credentials to end users. | Jamf Pro → Martini → Slack | Trigger from selected Jamf webhook events or scheduled compliance results, apply filtering and privacy rules, format a concise notification, and send it through the approved Slack API or webhook mechanism. Avoid placing tokens or unnecessary user information in messages. |
| Salesforce | Associate managed-device or user information with customer, field-service, or employee-support processes where Salesforce is an operational system. | Jamf Pro → Martini → Salesforce | Extract approved Jamf Pro inventory, normalize user and device identifiers, map the data to Salesforce objects, and perform controlled upserts. Use validation, deduplication, and bounded retries when the target API rejects or throttles a request. |
How to build a Jamf integration in Martini
Objective
Establish the Jamf Pro base URL and OAuth 2.0 client-credentials configuration without embedding secrets in workflows or mappings.
Instructions in Martini
- Create a dedicated Jamf Pro API client or service identity
- Store the client ID, client secret, base URL, and environment values as protected configuration
- Request bearer tokens and refresh them according to Jamf Pro token behavior
- Assign only the Jamf Pro roles and privileges required by the integration
Objective
Select an event-driven, scheduled, or API-led entry point based on the required latency and Jamf Pro event coverage.
Instructions in Martini
- Use a webhook workflow trigger for supported Jamf Pro events
- Use a scheduler for inventory polling and reconciliation
- Use an exposed Martini API for approved requests from adjacent systems
- Combine webhooks with scheduled reconciliation when complete change coverage is required
Objective
Call the appropriate Jamf Pro resource and retrieve complete, version-appropriate data before transformation or action.
Instructions in Martini
- Call the current Jamf Pro REST API where the required resource is available
- Implement the pagination model for Computers, Mobile Devices, or other collections
- Retrieve related Users, Groups, Policies, or Packages when the business rule requires context
- Use the Classic API only when an existing dependency requires a legacy endpoint
Objective
Coordinate Jamf Pro calls, downstream operations, validation, and asynchronous status checks as a maintainable Martini workflow.
Instructions in Martini
- Separate authentication, retrieval, transformation, target writing, and status handling into clear workflow stages
- Use controlled concurrency for large inventories or bulk operations
- Persist correlation identifiers for commands, webhook events, and target writes
- Distinguish command acceptance from later device execution
Objective
Convert Jamf Pro JSON payloads into a canonical model and target-specific structures without assuming every optional field exists.
Instructions in Martini
- Map stable IDs, serial numbers, ownership, operating-system, and management fields
- Normalize identifiers and timestamps consistently
- Handle missing inventory, ownership, and policy fields defensively
- Use reusable mappings for shared device and user structures
Objective
Enforce authorization, scope, compliance, and idempotency rules before writing data or issuing management actions.
Instructions in Martini
- Use serial numbers or stable Jamf identifiers rather than mutable device names as external keys
- Validate target Groups, Packages, Policies, and requested management actions
- Reject unauthorized commands and incomplete lifecycle requests
- Classify stale, unsupported, unassigned, or non-compliant devices explicitly
Common Jamf data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Computers | Synchronize macOS hardware, operating-system, inventory, ownership, and management information or target computer-management actions. | ServiceNow, Microsoft Intune, reporting databases, security platforms, Salesforce | Martini retrieves paginated resources, normalizes stable IDs and serial numbers, applies optional-field validation, and performs idempotent upserts or controlled commands. |
| Mobile Devices | Exchange iPhone and iPad inventory, ownership, management status, and compliance-related information. | ServiceNow, Microsoft Intune, identity platforms, reporting databases | Martini retrieves and maps device data, handles pagination and missing fields, and uses scheduled reconciliation to supplement selected webhook events. |
| Users | Resolve directory identities, device ownership, enrollment relationships, and lifecycle actions. | Microsoft Entra ID, Okta, Workday, ServiceNow | Martini matches users using approved stable identifiers, validates authorization, and links user changes to device or management workflows. |
| Groups | Organize devices and define targets for management policies, compliance reporting, or software deployment. | ServiceNow, Microsoft Intune, Jira, reporting platforms | Martini retrieves group membership, validates target scope, and uses groups as controlled inputs for policy, deployment, or reporting workflows. |
| Policies | Represent scheduled or triggered management actions such as software installation, inventory collection, or configuration changes. | Jira, ServiceNow, Slack, release-management platforms | Martini validates policy metadata, submits supported changes, records correlation data, and reports acceptance separately from device completion. |
| Packages | Manage software packages used in distribution and deployment workflows. | Jira, ServiceNow, release systems, Jamf Pro Groups and Policies | Martini can coordinate metadata, binary upload where supported, policy association, and status reporting while enforcing file-size and timeout controls. |
Authentication and security considerations
OAuth 2.0 and bearer tokens
Jamf Pro documents OAuth 2.0 client-credentials authentication for API clients. Martini can obtain and use bearer tokens without placing client secrets in workflow mappings or source code.
Least-privilege API access
Use a dedicated Jamf Pro API client or service identity with only the roles and privileges required by the workflows. Read-only inventory synchronization should not receive package-management or device-command permissions.
Secrets and sensitive data
- Store client IDs, client secrets, base URLs, and token configuration as protected environment values.
- Do not log complete access tokens or unnecessary user, serial-number, or security-related data.
- Restrict access to device inventory and user-assignment information according to organizational policy.
Operational considerations for Jamf integrations
Pagination and throttling
Computers and Mobile Devices collections can be large. Implement the pagination model for each endpoint, use controlled concurrency, and apply backoff when Jamf Pro capacity or throttling requires it.
Idempotency and reconciliation
Use stable Jamf identifiers or serial numbers for upserts. Webhooks cover selected events rather than every change, so pair event processing with scheduled reconciliation.
Asynchronous commands
Separate command acceptance from device execution. Store correlation data and check later status when devices are offline or process queued management actions asynchronously.
Version and schema changes
Confirm the target Jamf Pro version and endpoint behavior before deployment. Use defensive mappings for optional hardware, operating-system, ownership, and management fields.
Package transfer and errors
Package uploads may require binary transfer, larger payloads, temporary storage, and longer timeouts. Classify authentication, permission, validation, rate-limit, transient, and device-level failures before applying bounded retries.
Why use Martini instead of scripts or point-to-point integrations?
Centralized orchestration
Martini coordinates Jamf Pro API calls, webhook intake, scheduled reconciliation, downstream writes, and asynchronous status checks in workflows rather than scattering logic across independent scripts.
Reusable integration assets
Authentication, pagination, device normalization, validation, retry behavior, and target mappings can be organized into maintainable reusable integration logic. This reduces duplicated behavior across inventory, identity, compliance, and deployment processes.
Controlled API exposure
Martini can expose an API façade for approved lifecycle or management requests, applying authorization and business rules before invoking Jamf Pro. This avoids giving every calling system direct access to Jamf Pro credentials or privileges.
Operational reliability
- Support scheduled, event-driven, and API-led integration patterns.
- Apply consistent mapping, validation, error handling, and retry rules.
- Monitor workflow outcomes and distinguish queued commands from completed device actions.
Frequently asked questions
Jamf Pro can be integrated primarily through its REST APIs, which expose Computers, Mobile Devices, Users, Groups, Policies, Packages, and other resources. Selected Jamf Pro events can generate webhook-style notifications, while scheduled API synchronization supports reconciliation and reporting. OAuth 2.0 bearer-token authentication and Jamf Pro roles and privileges control access.
Yes. Martini can consume the Jamf Pro REST API, receive selected Jamf Pro webhook notifications, expose APIs for related systems, and orchestrate scheduled, event-driven, and asynchronous workflows. No native Martini Jamf connector is documented in the supplied research.
No. A dedicated Jamf connector is not required. Martini can use Jamf Pro's confirmed native integration mechanisms, including REST APIs, OAuth 2.0 authentication, selected webhook notifications, scheduled polling, and supported file or package operations.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Jamf. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Jamf, cloud infrastructure, or other third-party systems based on subscription, usage, and deployment model.
New implementations should generally use the current Jamf Pro REST API with OAuth 2.0 bearer tokens. Selected webhook events can support low-latency processing, and scheduled workflows should provide reconciliation. The legacy Classic API is mainly relevant when an existing dependency requires an endpoint not available in the current API.
No. Jamf Pro supports webhook-style notifications for selected events, but coverage does not necessarily include every resource or field change. Martini can receive and process supported notifications, while scheduled reconciliation fills coverage gaps and detects missed events.
Martini can paginate through Jamf Pro collections, map JSON payloads into a canonical model, and upsert target records using stable Jamf identifiers, serial numbers, or other documented keys. Device names should not be the sole key because they can change or be reused. Validation and normalization help maintain consistent results.
Martini can classify authentication, authorization, validation, throttling, transient server, and device-level failures, then apply bounded retries where safe. A successful Jamf Pro command submission may only indicate that the command was queued, so workflows should store correlation data and perform later status checks or reconciliation. Martini can also expose an API façade for approved downstream callers.
Related Martini documentation
Workflows
Operations
Build a maintainable Jamf integration with Martini
Use Martini to connect Jamf Pro APIs and selected webhook events with enterprise workflows, identity systems, ITSM platforms, reporting environments, and deployment processes.