11.34 Additions

What's new

Action logs

Action logs /v1 are new endpoints that report the mass actions run in Jamf Pro (delete, wipe, lock, and unmanage): who ran each one, what it targeted, and how every device has responded.

• GET /v1/action-logs
• GET /v1/action-logs/{id}
• GET /v1/action-logs/{id}/devices

GET /v1/action-logs returns a paginated list of actions. Use the filter parameter (RSQL) to narrow the list by actionType, status, requestor.name, requestor.type, target.type, target.name, target.deviceClass, target.deviceCount, or createdTime, for example actionType=="WIPE";status=="FAILED". The default sort is createdTime:desc. An unsupported sort or filter field, or a malformed query, returns 400.

GET /v1/action-logs/{id} returns one action and its statusSummary, which counts devices that are completed, failed, pending, and canceled. Jamf Pro updates these counters as devices report in. They aren't calculated from the device rows when you read them.

GET /v1/action-logs/{id}/devices returns a paginated list of every device in the action. Device details are a snapshot taken when the action was issued. outcome shows the device's current progress and stays PENDING until the device reports back.

Response: ActionLogDetailV1

{
  "id": "8470",
  "createdTime": "2026-06-17T09:14:00Z",
  "requestor": { "id": "42", "type": "USER", "name": "alex.torres" },
  "actionType": "WIPE",
  "target": {
    "type": "SMART_GROUP",
    "id": "88",
    "name": "All Exec Laptops",
    "deviceClass": "COMPUTER",
    "deviceCount": 19
  },
  "status": "MIXED",
  "statusSummary": { "completed": 18, "failed": 1, "pending": 0, "canceled": 1 }
}

Directory cache sync

Directory cache /v1 endpoints let you refresh a single directory user or group on demand and check the progress of the sync.

• GET /v1/directory-cache/sync-status
• POST /v1/directory-cache/sync/group
• POST /v1/directory-cache/sync/user

POST /v1/directory-cache/sync/user and POST /v1/directory-cache/sync/group start a sync that refreshes one user (username) or one group (group-name, as Jamf Pro currently stores it), along with every membership that includes them, from the directory service in directory-service-id. Both return 202 when the sync starts. Jamf Pro runs one sync at a time across all directory services, so a request made while another sync is running returns 409. A name longer than 512 characters returns 400.

GET /v1/directory-cache/sync-status returns state (RUNNING, NOT_RUNNING, or NEVER_RAN). While a sync is running, it also returns directoryServiceId, startTime, and currentStep. Poll it to find out when you can start the next sync.

Response: DirectorySyncStatusResponse

{
  "state": "RUNNING",
  "directoryServiceId": "1",
  "startTime": "2026-09-09T10:30:00Z",
  "currentStep": "groupMembershipStep"
}

Remote administration configurations move from /preview to /v1

Remote administration configurations /v1 are the stable version of the TeamViewer remote administration endpoints. The /preview endpoints have been removed in this release.

Requests and responses are unchanged. To migrate, change /preview/ to /v1/ in the path.

POST /v2/system/fedramp-initialize — new

Initializes a freshly installed FedRAMP instance and takes the Keycloak (OIDC broker) configuration directly. You no longer need to create the configuration first and pass its configUuid. Jamf Pro registers the configuration, stores the UUID it gets back, creates the initial federated account, records the activation code and Jamf Pro URL, acknowledges the EULA, and enables FedRAMP SSO.

This is a run-once operation. It succeeds only on a FedRAMP instance where no Jamf Pro users exist yet, the broker is enabled, and no broker UUID is stored. A non-FedRAMP instance is rejected with INVALID_STATE.

Request: FedRampBrokerInitializeV2. clientId, discoveryUrl, email, eulaAccepted, institutionName, jssUrl, and username are required. Provide exactly one of clientSecret or privateKeyJwt. Jamf Pro uses whichever one you send to choose the client authentication method. scopes defaults to ["openid", "profile", "email"] and productUserMapping defaults to EMAIL.

{
  "activationCode": "VFAB-YDAB-DFAB-UDAB-DEAB-EFAB-ABAB-DEAB",
  "institutionName": "Jamf",
  "eulaAccepted": true,
  "username": "admin",
  "email": "[email protected]",
  "jssUrl": "https://jamf.jamfcloud.com",
  "discoveryUrl": "https://keycloak.example.gov/realms/jamf/.well-known/openid-configuration",
  "clientId": "jamf-pro-admin-sso",
  "clientSecret": "s3cr3t-client-value"
}

User sessions /v2

User sessions /v2 are new versions of the active user session endpoints.

Migrating to the new endpoint versions

/v1/system/fedramp-initialize → /v2/system/fedramp-initialize

• Removed: configUuid. You don't need to create the broker configuration before you call this endpoint.
• Added: discoveryUrl and clientId (required), clientSecret or privateKeyJwt (send exactly one), and the optional productUsernameClaim, productUserMapping, and scopes.
• Responses and status codes are unchanged.

/v1/user-sessions → /v2/user-sessions

• Responses are unchanged: active returns an array of ActiveUserSession, and count returns ActiveUsersCount.