The Classic API Overview
The primary tool for programmatic access to data within the system and to allow for integrations with other systems is the Classic API. The base URL for the Classic API is located at /JSSResource on each Jamf Pro instance. Documentation and “Try it out” features are built into each instance of Jamf Pro, and can be accessed at /api.
Authentication and Authorization
The Classic API supports Basic Authentication and uses the standard User Accounts and Groups functionality of Jamf Pro. The Create, Read, Update and Delete privileges for an account or group within Jamf Pro correspond respectively with the POST, GET, PUT and DELETE HTTP methods. Furthermore, the Jamf Pro Server Object or Jamf Pro Server Setting should closely describe the endpoint for which permissions would be granted (e.g privileges for Advanced Computer Searches would be required to interact with the advancedcomputersearches endpoint).
HTTP Methods
The Classic API is a RESTful interface that uses standard HTTP methods to issue requests and receive responses.
- POST
-
POSTis used to create new objects or issue new actions. Most POST operations require that an XML body be passed with the request, however some endpoints support only path parameters. When an XML body is required, Jamf recommends setting the{id}path parameter to 0 (e.g./JSSResource/endpointname/id/0). Jamf Pro auto-assigns the object an ID and will respond to successful requests with the ID of the created resource. - GET
GETis used to retrieve information identified by the request-URI. Many endpoints support a{subset}path parameter, which tells the sever to return only certain subsets of information. Each endpoint supports a different array of subset values, which can be viewed by clicking the “Try it out” button for that specific endpoint within the API Reference page.- PUT
PUTis used to update existing records, identified by the request-URI. In most casesPUTwill only update the fields specified within the XML body and will leave values for fields not specified within the XML body as their previously defined values. Responses to successful requests will include the ID of the updated resource.- DELETE
DELETEis used to remove the resource identified by the request-URI. If successful the message response should include the ID of the deleted resource.
Schema
The Classic API is capable of producing XML and JSON format responses for GET type requests to the API. The API is limited to XML data formats for PUT and POST type requests. Jamf recommends including an Accept header Accept: application/json or Accept: text/xml to define the content type expected by the client.
Errors
The Classic API returns standard HTTP status codes for both successful and unsuccessful API calls. All errors returned will contain an HTML response that will contain a message with a description of the failure.
| Code | Description |
|---|---|
| 200 | Request successful |
| 201 | Request to create or update object successful |
| 400 | Bad request. Verify the syntax of the request specifically the XML body. |
| 401 | Authentication failed. Verify the credentials being used for the request. |
| 403 | Invalid permissions. Verify the account being used has the proper permissions for the object/resource you are trying to access. |
| 404 | Object/resource not found. Verify the URL path is correct. |
| 409 | Conflict |
| 500 | Internal server error. Retry the request or contact Jamf support if the error is persistent. |
Required Privileges
Determine the minimum required privileges for your Jamf Pro user account to interact with the Classic API.
Resources with Passwords
Passwords are attributes of many resources that are available via the Classic API. Jamf Pro 10.4 or greater allows the creation or modification of passwords for Jamf Pro accounts. You may perform a PUT or a POST to the /accounts/userid/{id} endpoint and include a <password> key with the desired password. Please reference the examples below to find proper utilization when creating or updating resources that include password key/pair values.
Example XML Model
<account> <password>Password</password> </account> Example XML Model
<computer_invitation> <ssh_password>Password</ssh_password> </computer_invitation> Example XML Model
<computer> <general> <remote_management> <management_password>Password</management_password> </remote_management> </general> </computer> - computerconfigurations
- Password of the management account for devices imaged using this configuration.
Example XML Model
<computer_configuration> <management> <password>Password</password> </management> </computer_configuration> Example XML Model
<directory_binding> <password>Password</password> </directory_binding> Example XML Model
<distribution_point> <read_only_password>Password</read_only_password> </distribution_point> Example XML Model
<distribution_point> <read_write_password>Password</read_write_password> </distribution_point> Example XML Model
<distribution_point> <http_password>Password</http_password> </distribution_point> - diskencryptionconfigurations
- Password for disk encryption configurations using institutional keys which include the private key (.p12 format).
Example XML Model
<disk_encryption_configuration> <institutional_recovery_key> <password>Password</password> </institutional_recovery_key> </disk_encryption_configuration> Example XML Model
<ldap_server> <connection> <account> <password>Password</password> </account> </connection> </ldap_server> Example XML Model
<policy> <account_maintenance> <management_account> <managed_password>Password</managed_password> </management_account> </account_maintenance> </policy> Example XML Model
<policy> <account_maintenance> <open_firmware_efi_password> <of_password>Password</of_password> </open_firmware_efi_password> </account_maintenance> </policy> Example XML Model
<policy> <account_maintenance> <accounts> <account> <password>Password</password> <account> </accounts> </account_maintenance> </policy> Example XML Model
<smtp_server> <password>Password</password> </smtp_server>