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
POST is 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
GET is 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
PUT is used to update existing records, identified by the request-URI. In most cases PUT will 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
DELETE is 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.

Common error codes and steps to troubleshoot failures.
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.

accounts
Password for the non-LDAP account being created or updated.

Example XML Model

<account>
    <password>Password</password>
</account>
computerinvitations
Password for the management account used for enrollment with this invitation.

Example XML Model

<computer_invitation>
    <ssh_password>Password</ssh_password>
</computer_invitation>
computers
Password for individual computer records' management account.

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>
directorybindings
Password for the service account used to bind computers to the directory service.

Example XML Model

<directory_binding>
    <password>Password</password>
</directory_binding>
distributionpoints
Password for the account that has read only access to the share.

Example XML Model

<distribution_point>
    <read_only_password>Password</read_only_password>
</distribution_point>
distributionpoints
Password for the account that has read/write access to the share.

Example XML Model

<distribution_point>
    <read_write_password>Password</read_write_password>
</distribution_point>
distributionpoints
Password for the account that has read access to the HTTP share.

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>
ldapservers
Password for the service account used to access the LDAP service.

Example XML Model

<ldap_server>
    <connection>
        <account>
            <password>Password</password>
        </account>
    </connection>
</ldap_server>
policies
Password used within the Management Account payload.

Example XML Model

<policy>
    <account_maintenance>
        <management_account>
            <managed_password>Password</managed_password>
        </management_account>
    </account_maintenance>
</policy>
policies
Password used within the EFI Password payload.

Example XML Model

<policy>
    <account_maintenance>
        <open_firmware_efi_password>
            <of_password>Password</of_password>
        </open_firmware_efi_password>
    </account_maintenance>
</policy>
policies
Password used within the Local Accounts payload.

Example XML Model

<policy>
    <account_maintenance>
        <accounts>
            <account>
                <password>Password</password>
            <account>
        </accounts>
    </account_maintenance>
</policy>
smtpserver
Password used to connect to the SMTP service.

Example XML Model

<smtp_server>
    <password>Password</password>
</smtp_server>