Help Make the Jamf Pro API Better

Jamf Pro has an extensive API, which enables integration with a wide range of third party apps, and the ability to code your own integrations. For my work, the API is essential, as the Jamf service we provide is too complicated to support via the GUI alone.

Unfortunately, sometimes the API lags behind when new features are introduced to Jamf Pro. With Jamf Pro 10, which was released at the end of October 2017, some new features and changes were introduced which broke existing integrations with AutoPkg, and sadly broke the ability to create a Self-Service Policy via the API.

Jamf And… AutoPkg?

At the Jamf Nation User Conference 2017, the release of Jamf Pro Version 10 was announced, and a key new feature, Patch, was revealed in more detail. Whilst currently restricted to a curated set of software, Jamf announced plans to open up the framework used by Patch to allow customers to add their own software titles, and AutoPkg was stated as a mechanism for adding the packages into the Patch system.

AutoPkg already integrates with Jamf, thanks to the work of @shea_craig and others who provided the JSSImporter processor. Note that this work is totally independent of Jamf. There are numerous workarounds that Shea had to implement in order to make JSSImporter work. Package upload has no published API, never has, and it turns out that in order to enable JSSImporter to import packages to some types of fileshare distribution points, namely Jamf Distribution Servers and Cloud Distribution Points, Shea had reverse-engineered how the Casper Admin application uploads packages using a private API.

In Jamf Pro 10, the method of upload has been changed. Casper Admin no longer works for uploading packages to JDS, CDP or the new Jamf Cloud Distribution Servers, therefore nor does JSSImporter. You can upload the metadata associated with a package as before, but the package itself is not uploaded. Currently you have to manually upload the package using the Jamf Pro Server GUI.

So, in many respects, the integration between Jamf and AutoPkg is broken.

And when it comes to Patch, there is absolutely no AutoPkg-Patch integration at present.

Jamf And… Creating a Policy with the API?

You can write an XML file containing the parameters required to create a policy. The good thing about the API is that you only need to provide non-default, required parameters. The remaining parameters are auto-created during the import. Apart from a few bugbears, such as the inability to refer to icons that already exist in the database, it worked.

But Jamf Pro 10 has broken it. Specifically, Policies created using the API which add a Self-Service entry will not show the policy name in Self Service, or indeed any text at all. Your end users will have to guess what the item is based on the icon. This is only solved by manually clicking Edit and Save in the JSS GUI for every policy. The reason for this is the new “Self Service Display Name” field, which is not available in the API. In the GUI some trickery auto-fills this field with the Policy Name if it is left empty, but this doesn’t work for new items imported via the API.

Self Service items with no title

I raised a Support Case, and publicised heavily to anyone who would listen, and was today told that the bug should be fixed when Jamf Pro 10.2 is released. Excellent news! But several bugs or sub-optimal aspects to the API remain.

Giving API the love it needs

A very telling statement from my excellent Jamf Support person alluded to the disjoint between the GUI and the API:

Aside from this, I’ve found that it is partially expected behaviour from our side, as any new implementation for the GUI, is not directly released as API available. New functionality in the API takes time to implement and sometimes does not match up with the exact timeline of the features.

Many customers have requested parity between the GUI and the API, such as this feature request by James Smith. A fully-functional API would not require reverse-engineering, hacks and workarounds to enable integration with established tools such as AutoPkg. It is the missing pieces that are causing the problems.

How do we help Jamf make the API better and easier to use? How do we ensure that Jamf don’t release new features at all until they are ready in the API? My supporter said it clearly:

… but generally speaking the Jamf Nation feature request will have more impact as other users can upvote it. To speed up the process, customers can create Feature Requests, and upvote them, which will get the priority for the feature getting created and released higher, by the amount of upvotes.

…to get the issue known and prioritised better, there is nothing else we can do from the Support Department, as the fixing of issues is prioritised from Cases attached to the PI(reporting the issue) and Upvotes for the FR for implementing new functionality.

I’m asking for your help in sharing the feature request link with anyone else you know who would like this upvoted, and asking them to also contact support regarding the PI if they are seeing it.

So now I’ve got to the point of this blog post, which is to make a plea for all Jamf Pro administrators who use the API not to just make do with the imperfections and broken bits, but to make Feature Requests, upvote existing ones, and contact Jamf Support get the profile of the API higher in the list of priorities of Jamf Developers.

Please upvote!

Please follow these links and upvote or like the feature requests and posts. And if the issues affect you, make a support request!

If you have a request you would like to see added to this list, let me know! And once again, please upvote!