GuidesRecipesAPI ReferenceChangelog
Log In
Changelog
Back to All
Improved

11.34 Changes

1 day ago by [email protected]

What's changed

Accounts can be excluded from ROPF migration

  • GET and POST /v1/accounts
  • GET and PUT /v1/accounts/{id}

Accounts have a new ropfMigrationScope key (AUTO or EXCLUDED) that controls whether the account can be migrated by ROPF. When you create an account and leave it out, it defaults to AUTO. Send EXCLUDED to create the account with migration turned off. When you update an account and leave it out, the stored value stays the same. Send EXCLUDED to return a migrated account to its default state. EXCLUDED returns 400 for FEDERATED accounts.

POST /v1/accounts and PUT /v1/accounts/{id} now also return 403 when the requesting account can't grant the privileges in the request. Existing integrations keep working, because the key is optional on both create and update.

Computer inventory create and update return validation and conflict errors

  • POST /v3/computers-inventory and /v4/computers-inventory
  • PATCH /v3/computers-inventory-detail/{id} and /v4/computers-inventory-detail/{id}

These endpoints now document two responses:

  • 400 when a field fails validation, or when macAddress and altMacAddress match. On create, 400 is also returned if the specified site doesn't exist.
  • 409 when the submitted udid, macAddress, or altMacAddress is already assigned to another computer. On create, this check also covers serialNumber.

Handle 409 as a duplicate-device conflict instead of a general failure. Requests that succeed are unchanged.

Device compliance information reports grace periods and per-registration detail

  • GET /v1/conditional-access/device-compliance-information/computer/{deviceId}
  • GET /v1/conditional-access/device-compliance-information/mobile/{deviceId}

Each record has two new keys.

  • gracePeriodSettingsState shows whether a non-compliant state would be held back by a Device Compliance grace period (enabled) and how long that period is (durationHours, between 1 and 720). This applies only to Intune. BeyondCorp records return null. durationHours is null when enabled is false.
  • registrations lists each of the device's registrations with that record's compliance vendor, such as one per originId for Intune or one per resource for BeyondCorp. Registrations marked for removal are included until the vendor sync deletes them. The array isn't sorted. To check whether a compliance change is being held back right now, read gracePeriodUntil on each registration.

These keys are additions, so existing parsers keep working.

Groups can be filtered by division

  • GET /v2/groups and /v2/groups/{id}

Groups now include a read-only divisionId key. It's null when the group has no division.

GET /v2/groups also has a new division-id query parameter that returns only groups in that division. If the access token has a division, division-id must match it. Site-scoped API clients must use a token with a division. The endpoint returns:

  • 400 when the division doesn't exist (INVALID_DIVISION, for tokens without a division) or the filter is invalid.
  • 403 when division-id doesn't match the token's division, or a site-scoped API client uses a token without a division.

Calls without division-id behave the same as before.

Managed software updates support Apple Vision Pro, tvOS, and visionOS

  • GET /v1/managed-software-updates/available-updates
  • GET and POST /v1/managed-software-updates/plans
  • POST /v1/managed-software-updates/plans/group
  • GET /v1/managed-software-updates/plans/group/{id} and /v1/managed-software-updates/plans/{id}
  • GET /v1/managed-software-updates/update-statuses, plus the computer-groups/{id}, computers/{id}, mobile-device-groups/{id}, and mobile-devices/{id} variants

objectType for devices in plans and update statuses now accepts and returns VISION_PRO. available-updates also returns tvOS and visionOS version lists next to macOS and iOS. If your code uses a fixed list of objectType values, add VISION_PRO so these devices aren't rejected or dropped.

Return to Service can retry enrollment

  • POST /v2/mdm/commands

The returnToService command data has a new optional shouldRetryEnrollment key. When it's true, the device retries enrollment if the first enrollment after the erase fails. Requires iOS 27 or later. Commands without the key behave the same as before.