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>