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:
- Base URL: A new gateway URL with regional routing, targeted API, and tenant scoping parameters.
- Authentication: Simplified to OAuth 2.0 client credentials only.
- 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/buildingsAfter (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}/buildingsLearn 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:
| Component | Description | Values |
|---|---|---|
{region} | The geographic region of your deployment | us, eu, apac |
{api} | The API you're targeting | pro, proclassic |
{tenantId} | The UUID of your tenant | A 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/buildingsUpdating 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-.../buildingsFor endpoints without a version prefix, insert the tenant scope directly after /api/{api}/:
# /devices/extensionAttributes -> /tenant/{tenantId}/devices/extensionAttributes2. 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/tokenPOST /v1/auth/keep-alivePOST /v1/auth/invalidate-tokenGET /auth/currentPOST /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 gateway | Platform API Gateway |
|---|---|
Create Buildings | create:pro:buildings |
Delete Computer Extension Attributes | delete: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-rolesneeds 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/searchreturn 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.