Overview
Jamf Pro is the Apple device management platform used by most enterprises that run Macs, iPhones and iPads at scale. It enrols Apple hardware, pushes configuration profiles and applications, enforces compliance policies, and maintains a detailed inventory record for every managed device. That inventory record is the part ReadyWorks is interested in: for each Mac, Jamf collects hardware identifiers, installed software, storage layout, FileVault encryption state, security posture, assigned user and purchasing detail, and refreshes it on a recurring inventory schedule.
The ReadyWorks connector talks to the modern Jamf Pro API over REST. It authenticates by sending the connection’s username and password as a Base64 Basic Authorization header to the bearer token endpoint (/api/v1/auth/token by default), reads the returned token from the token JSON node, and then presents it as Authorization: Bearer on every subsequent data call. Every shipped job then calls a single endpoint, /api/v1/computers-inventory, reads the results array, and writes it to its own staging table in the estate.
What separates the 24 shipped jobs from one another is the section query parameter. Jamf’s computer inventory endpoint returns a configurable slice of each computer record, and each ReadyWorks template asks for exactly one section and lands it in a table of its own. That gives you a normalised set of tables (hardware in one, applications in another, disk encryption in a third) rather than one very wide record per Mac, so you can enable only the sections you actually need and keep the rest switched off.
In a ReadyWorks context this is the Apple half of the endpoint estate. Pulling Jamf inventory alongside your Windows management source lets you reconcile a single device list across both platforms, match Macs to the people who hold them, find machines that have stopped checking in, check FileVault and security posture before a refresh or a migration wave, and assemble application inventory for rationalisation and licensing work. The purchasing and warranty section supports hardware refresh planning directly.
Direction: the connector is registered as bidirectional and the outbound job form is available, so you can build your own write-back jobs against the Jamf API. No outbound templates ship with it, so out of the box this connector reads only.
Connector Properties
Authentication Methods
The connector ships one authentication method. It exchanges a username and password for a short-lived Jamf Pro bearer token, then uses that token for the data calls.
NOTE: The account used here needs a Jamf Pro privilege set that allows read access to computer inventory. A read-only account is sufficient for every shipped job.
Method 1: JAMF (JAMF_user_token)
Connect to a Jamf API Rest Connector
Sends the configured username and password as a Base64-encoded Basic Authorization header to the Bearer Token End Point, extracts the token from the JSON node named in Bearer Token JSON Node, and attaches it as a Bearer token on all subsequent requests. Both the endpoint and the node ship with working defaults for Jamf Pro (/api/v1/auth/token and token), so in normal use you only supply the API Domain and the credentials. Point API Domain at your Jamf Pro tenant URL, including the scheme.
Connection Configuration Fields (8)
Authentication Configuration
Headers sent on the authentication call:
Headers sent on the data calls:
cURL options:
NOTE: Jamf Pro bearer tokens are short-lived. This matters when you decide how to set Single Authentication: leaving it at No re-authenticates on every pagination loop, and setting it to Yes reuses one token for the whole run, which will start returning 401 responses if a job runs longer than the token lifetime.
Inbound Job Fields Enabled (44)
Inbound jobs expose the full REST job form, including the pagination and three-level enumeration groups, even though no shipped template uses either.
Outbound Job Fields Enabled (13)
The outbound job form is fully enabled so you can author your own write-back jobs against the Jamf Pro API, although no outbound template ships with the connector.
Inbound Job Templates (24)
All 24 inbound templates call the same endpoint, /api/v1/computers-inventory, and differ only in the section parameter they request and the table they write to. Twenty-three cover one inventory section each, and the twenty-fourth requests every section in a single call.
Job Template Configuration
Settings Common to All Twenty-Four Templates
Settings That Vary by Template
Job Parameters and Enumeration
Device Applications
API data parameters:
Device Storage
API data parameters:
Device General
API data parameters:
Device Disk Encryption
API data parameters:
Device Purchasing
API data parameters:
Device User and Location
API data parameters:
Device Configuration Profiles
API data parameters:
Device Printers
API data parameters:
Device Services
API data parameters:
Device Hardware
API data parameters:
Device Local User Accounts
API data parameters:
Device Certificates
API data parameters:
Device Attachments
API data parameters:
Device Plugins
API data parameters:
Device Package Receipts
API data parameters:
Device Security
API data parameters:
Device Operating System
API data parameters:
Device Licensed Software
API data parameters:
Device iBeacons
API data parameters:
Device Software Updates
API data parameters:
Device Extension Attributes
API data parameters:
Device Content Caching
API data parameters:
Device Group Memberships
API data parameters:
Devices: All Data
API data parameters:
section:
APPLICATIONS,STORAGE,GENERAL,DISK_ENCRYPTION,PURCHASING,USER_AND_LOCATION,CONFIGURATION_PROFILES,PRINTERS,SERVICES,HARDWARE,LOCAL_USER_ACCOUNTS,CERTIFICATES,ATTACHMENTS,PLUGINS,PACKAGE_RECEIPTS,SECURITY,OPERATING_SYSTEM,LICENSED_SOFTWARE,IBEACONS,SOFTWARE_UPDATES,EXTENSION_ATTRIBUTES,CONTENT_CACHING,GROUP_MEMBERSHIPS
NOTE: Every template ships with Enabled set to No. Nothing runs until you enable the sections you want.
NOTE: Each enabled template performs its own full sweep of the computer inventory. Enabling all 24 means 24 complete passes over your Mac estate per run, so enable only the sections you will actually reconcile against.
NOTE: The templates cover computer inventory only. Mobile devices, Jamf users, policies, scripts and smart group definitions are not pulled by any shipped job, although you can add jobs for them on the same connection.
Outbound Job Templates (0)
No outbound templates ship with this connector. The outbound job form is enabled, so you can author write-back jobs against the Jamf Pro API yourself.
Preparing Jamf Pro
ReadyWorks connects to Jamf Pro through the Jamf Pro API using OAuth 2.0 client credentials. This method uses a dedicated API client with its own permissions, independent of any administrator account. Complete both steps below in Jamf Pro before configuring the connection in ReadyWorks.
Step 1: Create the API Role
The API role defines what ReadyWorks is allowed to read.
- In Jamf Pro, go to Settings > System > API Roles and Clients
- Open the API Roles tab and click New
- Enter a descriptive display name, for example
ReadyWorks Read-Only - Add the following privileges:
- Read Computers
- Read Computer Inventory Collection
- Read Smart Computer Groups
- Read Static Computer Groups
- Read Mobile Devices
- Read Smart Mobile Device Groups
- Read Static Mobile Device Groups
- Read Computer Extension Attributes
- Read Mobile Device Extension Attributes
- Read Departments
- Read Buildings
- Read Sites
- Read User
- Click Save
NOTE: Every privilege in this role is read-only. ReadyWorks uses this access to collect device inventory, group membership, and organizational data from Jamf Pro. It does not create, modify, or delete any objects in Jamf Pro.
Step 2: Create the API Client
The API client is the identity ReadyWorks authenticates as.
- On the API Clients tab, click New
- Enter a display name, for example
ReadyWorks Integration - Assign the API role created in the previous step
- Set an access token lifetime. The default is acceptable for most environments
- Click Save
- Click Edit, turn on Enable API Client, and save again
- Click Generate Client Secret and confirm
- Copy the client ID and client secret and store them securely. These values are needed to configure the connection in ReadyWorks.
NOTE: Jamf Pro displays the client secret only once. If it is lost, generate a new secret and update the ReadyWorks connection with the new value.