The Jamf Protect API is a GraphQL API for programmatically reading security data from Jamf Protect, including alerts, analytics, computers, plans, prevent lists, unified logging filters, and audit logs. A set of mutations lets you make updates.
Jamf Protect exposes a single GraphQL endpoint. You send a query naming exactly the fields you want and receive a response in that shape.
You reach it through the Platform API Gateway, using one integration that also reaches Jamf Pro, blueprints, devices, and the rest of the platform under a single permission model. The GraphQL schema itself is unchanged, so every query, mutation, and type documented here behaves exactly as it always has.
Before you start
Jamf Protect sits behind the Platform API Gateway and uses the same authentication, regions, and permission model as every other Jamf API. One integration covers Protect alongside the rest of the platform.
- New to the gateway? Getting started walks you from creating an integration to your first call.
- Already have an integration? Platform API fundamentals is the reference for tokens, regions, permissions, pagination, and errors.
Protect authorization requires an integration that uses the client credentials flow. Tokens from the authorization-code flow cannot authorize Protect operations.
Scope and request context
Protect is a product API, so you can reach it from an integration scoped at either level. The scope you choose decides which context header you send with every request.
| Scope level | What it reaches | Context header |
|---|---|---|
| Tenant | The specific Protect instances you select | X-Tenant-Id |
| Platform environment | The product APIs of every tenant in the environment, including Protect | X-Environment-Id |
Send the tenant or environment UUID in the matching header on every request. Copy either ID from the Integration details panel in Jamf Account by clicking the relevant pill. See Scope levels and Request context for the full picture.
An environment-scoped token carries no tenant ID claim. If a Protect operation returns
403under an environment-scoped integration, create one scoped to the tenant and send its ID inX-Tenant-Id.
Endpoint
POST https://{region}.api.jamfcloud.com/protectProtect's namespace segment is protect, and all requests are POST requests with a JSON body of the form:
{ "query": "<your GraphQL query>", "variables": { } }Send your access token in the Authorization header as a Bearer token, and your context in X-Tenant-Id or X-Environment-Id to match your integration's scope. {region} is us, eu, or apac, matching the region your Protect tenant is hosted in.
Unlike the REST APIs on the gateway, Protect exposes one endpoint for every operation, so the operation name in your query body determines what runs and which permission it needs.
Required permissions
Each GraphQL operation requires a capability permission on your integration, in the form {capability}:{action}.
Because GraphQL has one endpoint and one HTTP verb, permissions map to operation names. Grant the capability that covers the operations you call.
Endpoint security
| Capability | Operations |
|---|---|
protection-plans:read | getPlan, listPlans |
detection-analytics:read | getAnalytic, listAnalytics |
detection-analytics:update | updateAnalyticSet |
threat-alerts:read | getAlert, listAlerts |
threat-alerts:update | updateAlerts |
prevent-lists:read | getPreventList, listPreventLists |
prevent-lists:create | createPreventList |
prevent-lists:update | updatePreventList |
prevent-lists:delete | deletePreventList |
threat-definition-versions:read | listThreatPreventionVersions |
unified-logging-filters:read | getUnifiedLoggingFilter, listUnifiedLoggingFilters |
unified-logging-filters:create | createUnifiedLoggingFilter |
unified-logging-filters:update | updateUnifiedLoggingFilter |
unified-logging-filters:delete | deleteUnifiedLoggingFilter |
security-audit-log:read | listAuditLogsByDate, listAuditLogsByOp, listAuditLogsByUser |
Inventory
These capabilities are shared across the Jamf platform. The same devices:read covers device inventory in Jamf Pro and in Jamf Protect.
| Capability | Operations |
|---|---|
devices:read | getComputer, listComputers, requestComputerTimeline |
devices:update | updateComputer, setComputerPlan |
devices:delete | deleteComputer |
users:read | listUsers |
users:delete | deleteUser |
Grant every action your integration uses.devices:updatecovers writes only, so adddevices:readif your integration reads a computer before updating it. Some operations require two capabilities together.
Check the tables above for each operation you call. A few capability names differ from the operation verb, including setComputerPlan, which falls under devices:update, and requestComputerTimeline, which falls under devices:read.
Reference
- Queries: read data from Jamf Protect
- Mutations: create, update, and delete data
- Types: objects, inputs, enums, and scalars
- Example Calls: practical, runnable recipes
Building across more than one Jamf product? Platform API fundamentals covers the conventions every Jamf API shares.
Jamf Protect API: Overview · Queries · Mutations · Types · Example Calls