Introducing Platform APIs and the Platform API Gateway

There are a lot of reasons to use Jamf APIs: automating a fleet, extending Jamf functionality, rolling out the same setup across a hundred customers or just experimenting with an endpoint to see what comes back.

Whichever the case, the friction has been the same: a separate credential for every product, privilege lists that are hard to navigate and data models that do not line up.

The Platform API Gateway and Platform APIs are now generally available, and they change that unit: one authentication model for integrating with Jamf, permissions that are easy to navigate and are scoped by capability rather than by product, and a new tier of consistent and more powerful APIs that belong to the platform.

One gateway, the whole platform

The Platform API Gateway offers a single endpoint and one authentication model for integrating with Jamf, whatever sits on the other side: your IdP, your SIEM, your ITSM, or — if you are a partner — a product your customers buy.

At launch it fronts Platform APIs and product APIs across Jamf Pro, Jamf Protect, Jamf Account, and a first set of Jamf Security Cloud capabilities.

Authorization built on OAuth 2.0

Register a client, exchange for short-lived tokens and leave long-lived keys in config files behind. Credentials live in the new Integrations space in Jamf Account. One set of secure credentials for the whole Jamf platform.

Permissions organized by capability

Rather than hunting a huge dropdown of product-shaped privileges, you pick a capability category cutting through all products (inventory, deployment, compliance and more) and the actions it supports: create, read, update, delete, deploy or execute. Apply them to a whole category or one capability at a time.

Scope across the Jamf platform

Reach Jamf capabilities through the new platform environment scope level, which includes Platform APIs. A platform environment groups your product tenants that work together, one per product type. Most customers have one already, but until everyone does, tenant scoping will be available for single-product access. A third scope level is organization management, which deals with Jamf Account administration.

Platform APIs: built for the platform, not bolted onto a product

Platform APIs sit above the product layer and are built once, consistent by design and aimed at the workflows that work across product boundaries. Here is the first set:

Blueprints: Declarative device management inside your pipeline. Create, deploy and manage blueprints programmatically. Custom declarations are included, so there’s no limit to what you can do.

Declaration reporting: Query the state of declarations applied to your devices, by device or by identifier. Blueprints deploys the configuration; this proves it landed.

Compliance benchmarks: Create and manage benchmarks, retrieve rule-level results and query fleet-wide state against frameworks, including CIS and NIST.

Devices: One standardized source of truth for your fleet. You can now filter by last inventory update to check or parse changes rather than polling your entire fleet and then figuring out the difference.

Device groups: The same standardization for groupings, so scoping logic stops being rewritten per product.

Device management actions: Check in, erase, restart, lock, unmanage and more across your entire fleet without a per-product command interface.

The previous three device-related APIs are product agnostic by design, but at launch they cover devices managed by Jamf Pro. Coverage will expand to other Jamf products in the future.

AI policies: Part of our new AI Governance capability, so AI oversight sits in the same automation as every other control you enforce.

Audit: One record of administrative activity across the platform instead of one per product. Answer who changed what, and when, in a single query.

Organization management: A set of APIs for managing your organization settings, including your integrations, licensing and SSO.

Together, these APIs close loops: deploy a blueprint and confirm it landed, benchmark a fleet and hand the result to your GRC tool, act on a device straight from a service desk ticket and more.

How we build from here

Unifying the surface is also our chance to shape its development in direct response to your feedback.

Your feedback lands in the platform: Existing gaps are being worked into Platform APIs rather than patched product by product. You'll see this most clearly with the Classic API: rather than patch the gap with the Jamf Pro API piece by piece, this closes it at the platform level.

Versioning and deprecation you can plan around: Clearer policy and operations, so you know what is being deprecated and when, and what to use instead. Deprecation only starts once there is feature parity or a deliberate decision to retire a capability.

One consistent style: Every new API follows our published API style guide, so the second Platform API you pick up behaves like the first.

Child organizations: Support for managing customer accounts beneath a parent organization is coming soon.

Integrations worth building: We are also working to make building a complete Jamf integration both easier and better rewarded.

Preview APIs: A defined preview stage for trying new APIs early and telling us what is wrong before the contract sets.

One gateway, many ways in

More than one-third of Jamf customers already integrate with at least one Jamf API, and they do not sort neatly into types. An MSP engineer scripts a one-off in the morning and runs versioned fleet configuration in the afternoon. An enterprise admin who has never written Go still wants configuration reviewed in Git. A technology partner engineer shipping a full integration still wants a command line for debugging.

Not everyone will use APIs the same way and this also goes for its entry points, which lie on a spectrum. However, every point runs through the same gateway, on the same credential, with the same permission model.

Everyone knows how to operate the Jamf platform using the UI, but you can automate a lot of everyday tasks through our new Jamf CLI tool, from a device action, to a configuration diff across instances. Next up, we have our officially supported Jamf platform Terraform provider. Terraform helps automate and version control (GitOps) your fleet.

When you build on the platform, you have a couple of main options. You have the raw APIs when you need to build something that does not exist yet, or the Go SDK for the same reach with less plumbing.

Just know that there are no cliff edges between each way of operating or building with Jamf. Start with a script, grow into a pipeline, build a product on it later.

Get started

The Platform API Gateway and Platform APIs are available now in Jamf Account. Reference documentation is on the Jamf Developer Portal.