Skip to content

Sync Pipeline

Karthikeyan Marappan edited this page Apr 20, 2026 · 3 revisions

How the Sync Pipeline Works

Each Run Sync executes four steps in sequence. Steps still within the cache window are skipped unless you force a refresh. All steps are scoped to the active environment.


Step 1 — Fetch AxM Devices

Downloads the complete device list from your ABM or ASM organisation via /v1/orgDevices.

Captured per device: serial number, AxM device UUID, device status (ACTIVE/RELEASED), purchase source type and ID, order number, order date, product family, model string.

Cache: controlled by Device Cache (days). Skip if fresh, unless Force Refresh Devices is on.

Authentication: ES256 JWT client assertion (10-min lifetime). OAuth access token (1-hour TTL) cached in Keychain per environment.

Pagination: 1,000 devices per page, follows cursor until all pages are downloaded. Supports cursor resume — if interrupted, the next run continues from the saved cursor rather than starting over.


Step 1b — Fetch MDM Server Assignments

Fetches all MDM servers registered in the organisation and maps device serial numbers to their assigned server.

Endpoints:

GET {baseURL}/v1/mdmServers
GET {baseURL}/v1/mdmServers/{id}/relationships/devices

Captured per device: MDM server UUID, server name, server type (MDM or APPLE_CONFIGURATOR).

Concurrency: all server device lists are fetched in parallel using a task group.

Gate: only runs when Step 1 fetched live data (rawABM non-empty). If the device cache is fresh, Step 1b is skipped and existing MDM assignment data in CoreData is preserved unchanged. Force Refresh Devices triggers both Step 1 and Step 1b together.

Result: each device in the merged database is stamped with its MDM server name (or left as Unassigned if it does not appear in any server's device list).


Step 2 — Fetch Jamf Devices

Downloads all computers and mobile devices from Jamf Pro.

Device type Endpoint
Macs GET /api/v3/computers-inventory
Mobile GET /api/v2/mobile-devices/detail

Captured per device: serial number, Jamf ID, name, model, OS version, FileVault status, managed status, last contact, last enrolled, existing warranty date, vendor, AppleCare ID, PO number, PO date.

Authentication: OAuth2 client credentials. Token cached in Keychain per environment.

After both steps, devices are merged by serial number into three groups:

Badge Meaning
In Both Found in both ABM/ASM and Jamf
AxM Only In ABM/ASM, not in Jamf
Jamf Only In Jamf, not in ABM/ASM

Step 3 — Fetch AppleCare Coverage

For each device with an AxM Device UUID, calls:

GET {baseURL}/v1/orgDevices/{deviceId}/appleCareCoverage

Captured: coverage status, end date (YYYY-MM-DD), agreement number, raw JSON.

When a device has multiple coverage records, the record with the latest end date is used.

HTTP 404 → No Coverage Info (no AppleCare plan on file).

Concurrency: 3 parallel requests, 500ms pause between chunks — conservative to respect Apple's rate limit.

Which devices are checked: Only devices with a valid AxM Device UUID. With Do Not Refetch on, already-checked devices are skipped. With a Coverage Fetch Limit, a maximum of N devices are checked per run; the next run resumes from where the last stopped.

Scope: respects the Sync Device Types setting — Mac Only or Mobile Only runs skip the other device type entirely.


Step 4 — Jamf Update (Write-back)

For every In Both device with a coverage result, sends a PATCH to Jamf Pro.

Fields written:

Jamf field Source
warrantyDate / warrantyExpiresDate Coverage end date from Apple's API
appleCareId Agreement number from Apple's API
vendor "purchaseSourceType (purchaseSourceId)" from ABM/ASM
poNumber Order number from ABM/ASM
poDate Order date from ABM/ASM (YYYY-MM-DD)
Device type Endpoint
Mac PATCH /api/v3/computers-inventory-detail/{id}
Mobile PATCH /api/v2/mobile-devices/{id} (dates require ISO 8601 format)

Concurrency: 8 parallel PATCH requests. A shared Jamf token is fetched once before the loop.

External change detection: if any of the above fields are cleared or modified in Jamf after a successful sync, the next run detects the mismatch and re-queues those devices for write-back automatically.

Write-back statuses:

Status Meaning
Synced PATCH succeeded
Failed PATCH returned an error
Skipped No Jamf ID, or AxM-only
Pending Coverage fetched, write-back not yet attempted

Stopping mid-run

Click Stop Sync at any time. Coverage fetched in Step 3 and write-backs completed in Step 4 are saved immediately. The next Run Sync resumes from the earliest incomplete step.

Clone this wiki locally