Updating existing Jamf Pro integrations

Already building on the Jamf Pro or Classic API? Here's what to update to start using the Platform API Gateway (Beta).

The Platform API Gateway (Beta) is the new home for Jamf API integrations. If you have existing integrations built against the Jamf Pro API gateway, the good news is that most of your work is already done — request bodies, response schemas, pagination and filtering all stay the same. What changes is where you send requests, how you authenticate, and how permissions are referenced. This guide walks you through each of those updates.

What's changing

There are three areas where you need to make updates:

  1. Base URL: A new gateway URL with regional routing, targeted API, and tenant scoping parameters.
  2. Authentication: Simplified to OAuth 2.0 client credentials only.
  3. Permissions format: New colon-delimited privilege strings.

1. Update your base URL

Before (Jamf Pro API gateway)

Requests go directly to your Jamf Pro instance:

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

After (Platform API Gateway)

Requests route through a regional gateway, specifying the API (pro or proclassic) and your tenant ID:

GET https://{region}.apigw.jamf.com/api/pro/v1/tenant/{tenantId}/buildings
📘

Learn more about tenants and the tenant ID in Tenant and tenant ID.

Understanding the new path structure

Three new components appear in every request URL:

ComponentDescriptionValues
{region}The geographic region of your deploymentus, eu, apac
{api}The API you're targetingpro, proclassic
{tenantId}The UUID of your tenantA UUID, e.g. e77c1408-10c8-4007-b177-abc9157fbcaa

Every endpoint follows this pattern:

/api/{api}/{version}/tenant/{tenantId}/{resource-path}
📘

Version prefixes are preserved (e.g. /v1/, /v2/). You don't need to change which version of an endpoint you're calling — only where the new path components are inserted.

Before and after

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

# After
curl https://us.apigw.jamf.com/api/pro/v1/tenant/e77c1408-10c8-4007-b177-abc9157fbcaa/buildings

Updating your code (example)

If your integration builds URLs from a base URL variable, the update is straightforward — swap the base URL and inject the new path components:

# Before
BASE_URL = "https://yourserver.jamfcloud.com/api"

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

# Example: get_url("/v1/buildings")
# Result:  https://yourserver.jamfcloud.com/api/v1/buildings
# After
API = "pro"  # e.g. pro, proclassic
REGION = "us"
TENANT_ID = "e77c1408-10c8-4007-b177-abc9157fbcaa"
GATEWAY_URL = f"https://{REGION}.apigw.jamf.com/api/{API}"

def get_url(path):
    import re
    scoped = re.sub(
        r"^(/v\d+)(/.+)",
        rf"\1/tenant/{TENANT_ID}\2",
        path
    )
    return f"{GATEWAY_URL}{scoped}"

# Example: get_url("/v1/buildings")
# Result:  https://us.apigw.jamf.com/api/pro/v1/tenant/e77c1408-.../buildings

For endpoints without a version prefix, insert the tenant scope directly after /api/{api}/:

# /devices/extensionAttributes -> /tenant/{tenantId}/devices/extensionAttributes

2. Switch to OAuth 2.0 client credentials

Before (Jamf Pro API gateway)

The Jamf Pro API gateway supports two ways to obtain a bearer token:

  • Basic authentication: Username and password, token via /v1/auth/token
  • OAuth 2.0 client credentials: Client ID and secret, token via /v1/oauth/token

After (Platform API Gateway)

The Platform API Gateway uses OAuth 2.0 client credentials only. Basic auth is not supported. The token endpoint is: https://{region}.apigw.jamf.com/oauth2/token.

📘

For details on obtaining a token, see Request an access token.

What to remove

If your integration calls any of the following Jamf Pro API gateway endpoints, remove them — they don't exist on the Platform API Gateway:

  • POST /v1/auth/token
  • POST /v1/auth/keep-alive
  • POST /v1/auth/invalidate-token
  • GET /auth/current
  • POST /v1/oauth/token

3. Update your permissions

Same permissions, new format.

What changed

Permission strings have moved from a space-separated format to a consistent, colon-delimited format following {action}:{product}:{resource-slug}. This affects API role management, permission checks and any logic that references permission names.

Jamf Pro API gatewayPlatform API Gateway
Create Buildingscreate:pro:buildings
Delete Computer Extension Attributesdelete:pro:computer-extension-attributes

The action comes first in lowercase, followed by the product in lowercase, followed by the resource in kebab-case. Both the Jamf Pro API and Classic API use pro as the product.

Impact on your integration

This change matters if you:

  • Manage API roles programmatically — Any code that creates or updates API roles via /v1/api-roles needs to use the new permission strings in the request body
  • Check permissions in your application logic — Any hardcoded permission strings need updating
  • Use the permissions search endpoint — Queries against /v1/api-role-privileges/search return the new format
📘

A full mapping of Jamf Pro API gateway permissions to their Platform API Gateway equivalents is available in the Jamf Pro permissions map.