Updating existing Jamf Pro integrations

For integrations built against the Jamf Pro API or the Classic API, request bodies, response schemas, pagination, and filtering stay the same. Four things change: where you send requests, how you authenticate, how you pass tenant context, and how permissions are named.

This guide covers each of those, then lists the endpoints and schemas that differ so you can check your integration before switching.

What's changing

1. Update your base URL

Before

Requests go directly to your Jamf Pro instance:

GET https://yourserver.jamfcloud.com/api/v1/buildings

After

Requests route through a regional gateway, naming the API you're targeting:

GET https://{region}.api.jamfcloud.com/pro/v1/buildings

Every endpoint follows this pattern:

/{api}/{version}/{resource-path}

Before and after

# Before
curl https://yourserver.jamfcloud.com/api/v1/buildings

# After
curl https://us.api.jamfcloud.com/pro/v1/buildings \
  -H "X-Tenant-Id: e77c1408-10c8-4007-b177-abc9157fbcaa"

2. Move tenant context into a header

Your Jamf Pro hostname used to identify your tenant. On the gateway, one host serves every customer in a region, so you name your tenant explicitly:

X-Tenant-Id: <your-tenant-UUID>

Find the UUID in the Integration details panel in Jamf Account by clicking the tenant pill.

Platform environment-scoped integrations send X-Environment-Id instead. Jamf Pro and Classic are product APIs, so tenant scope is what you want for the work in this guide.

Updating your code

If your integration builds URLs from a base URL variable, swap the base URL and move the tenant into a default header:

# Before
BASE_URL = "https://yourserver.jamfcloud.com/api"
HEADERS = {"Authorization": f"Bearer {token}"}

def get_url(path):
    return f"{BASE_URL}{path}"

# get_url("/v1/buildings") -> https://yourserver.jamfcloud.com/api/v1/buildings

# After
API = "pro"          # "pro" or "proclassic"
REGION = "us"        # "us", "eu", or "apac"
TENANT_ID = "e77c1408-10c8-4007-b177-abc9157fbcaa"

BASE_URL = f"https://{REGION}.api.jamfcloud.com/{API}"
HEADERS = {
    "Authorization": f"Bearer {token}",
    "X-Tenant-Id": TENANT_ID,
}

def get_url(path):
    return f"{BASE_URL}{path}"

# get_url("/v1/buildings") -> https://us.api.jamfcloud.com/pro/v1/buildings

Your path-building logic stays as it was. Set the header once on your session or client and every call includes it.

3. Switch to OAuth 2.0 client credentials

Before

The Jamf Pro API supports three authentication methods:

• Basic authentication: username and password, used to obtain a bearer token from /v1/auth/token
• Bearer token: a JWT obtained from basic auth, kept alive via /v1/auth/keep-alive
• API client credentials: OAuth 2.0 client credentials, with tokens from /v1/oauth/token

After

The Platform API Gateway uses OAuth 2.0 client credentials. Your credentials come from an integration you create in Jamf Account rather than from your Jamf Pro instance, and the token endpoint moves to the gateway.

Getting a token

The token exchange is the same for every API behind the gateway. See
Request an access token for the call, and
Token lifetime for the two behaviors that differ from the
Jamf Pro API: tokens last 900 seconds with no keep-alive, and they are region-locked.

What to remove

If your integration calls any of these, delete those calls:

4. Update your permission references

What changed

Permissions moved from human-readable privilege names to capability permissions, organized by what you're trying to do rather than by product.

Every permission follows this pattern:

{capability}:{action}

The capability comes first in kebab-case, followed by the action in lowercase. Six actions are available: create, read, update, delete, deploy, and execute. They are lowercase and case-sensitive.

Capabilities span products, so one devices:read covers device inventory across Jamf Pro, Jamf Protect, and the platform Devices API.

Impact on your integration

Update your code if you:

• Check permissions in application logic. Hardcoded privilege strings need updating to the capability form.
• Grant least privilege deliberately. Review your capability list against what your integration calls, since capabilities span products more broadly than the old per-product privileges did.

For the complete list, see the Jamf Pro permissions map.

5. Check endpoint and schema availability

Most of the Jamf Pro API surface is available through the gateway. A few groups are not, and one group was removed deliberately.

Removed by design

Authentication endpoints. These supported the legacy basic auth and bearer token flows, and the gateway token endpoint replaces all of them.

/v1/auth/token, /v1/auth/keep-alive, /v1/auth/invalidate-token, /auth/current, /auth/keepAlive, /auth/invalidateToken, /v1/auth, /v1/oauth/token, /v1/oauth2/session-tokens

API clients, API roles, and peripherals. Credential management moved to Jamf Account, and the peripherals endpoints were retired.

Unavailable through the gateway

Local Admin Password (LAPS). The /v2/local-admin-password/ set is unavailable. If your integration rotates, audits, or retrieves local admin passwords, keep those calls on the Jamf Pro API for now.

/v2/local-admin-password/pending-rotations, /settings, /{clientManagementId}/accounts, /{clientManagementId}/account/USERNAME/password, /audit, /history, /{guid}/password, /{guid}/audit, /{guid}/history, /{clientManagementId}/history, /{clientManagementId}/set-password

Remote administration (TeamViewer). The /preview/remote-administration-configurations preview endpoints are unavailable.

Schema differences

Most shared schemas are identical between the two specifications. The differences are a deprecated field handled differently, an enum value added or removed, or a property not carried over. Core data structures are unchanged.

Differences worth checking if you use strict deserialization:

• MdmCommand: the gateway version omits dateCompleted, commandError, and profileId
• MdmCommandType: three enum values are absent, namely PROFILE_LIST, INSTALLED_APPLICATION_LIST, and PROVISIONING_PROFILE_LIST
• ComputerPrestageV3: Platform Single Sign-on fields such as authUrl are absent
• EnrollmentSettingsV4: personalDeviceProfileEnrollmentType is deprecated in the Jamf Pro API and remains an active enum on the gateway
• UserAccount: accountType is absent
• Package: sha3512 is absent
• SiteObject: the gateway adds Android Device to the object type enum

Other schemas with differences: ApplicationAttributes, ApplicationConfiguration, Attributes, CloudLdapServerRequest, EnrollmentProcessTextObject, InventoryListMobileDevice, JamfProInformationV2, JamfProtectPlan, MdmClientType, MdmCommandRequest, MobileDeviceGeneral, MobileDeviceLostModeLocation, MobileDevicePrestageV3, MobileDeviceSecurity, NotificationType, OidcLoginDispatchResponseV2, PlanSearchResults, ProtectSettingsResponse, ProtectUpdatableSettingsRequest, SettingsCommand, SharedDeviceConfiguration

Migration checklist

• Create an integration in Jamf Account, scoped to your Jamf Pro tenant, with the capabilities your workflow needs
• Note your region and tenant UUID, one of us, eu, or apac, plus the UUID from the Integration details panel
• Update your base URL to https://{region}.api.jamfcloud.com/{pro|proclassic}
• Add the X-Tenant-Id header to your session defaults, and remove any /tenant/{tenantId}/ path segments if you built against the beta
• Switch authentication to OAuth 2.0 client credentials against the gateway token endpoint
• Remove the retired auth calls, including keep-alive and invalidate-token
• Handle 900-second tokens, refreshing on a timer based on expires_in
• Update permission strings to the capability form, and move any API role management into Jamf Account
• Check endpoint coverage for LAPS and TeamViewer calls, keeping those on the Jamf Pro API
• Review schema differences against your data models if you validate strictly
• Update your tooling to GA-compatible versions of jamf-cli, the Terraform provider, or the Go SDK
• Test in staging before switching production traffic

Related articles

• Getting started: create an integration and make your first call
• Platform API fundamentals: auth, scope levels, regions, permissions, pagination, and errors
• Jamf Pro permissions map: privilege names to capability equivalents