In today’s session, Jamf product experts, Tani Kawleit, Doug Rhoten and Brad Becker shared how they see customers using APIs and explained some unique things they’ve built to enhance the user experiences. Additionally, they took a look at when and why it’s important to use different API options.
Doug started off by providing an overview of the Customer API by explaining use cases in the real world, such as updating building and departments. He also offered an example case that determined if devices are managed and using that information to update static groups accordingly, all using scripting and the API. With the Jamf server API, admins are able to leverage the API to: retrieve, add, update and delete data. These commands are standard REST HTTP methods (GET, POST, PUT and DELETE). Detailed documentation and interactive example exercises are provided in every install of the Jamf server. The API information can be found at https://.com:8443/api.
Doug went on to show off the 10 new API endpoints that were added to Jamf in 9.82.
A notable example was “/computerapplications” which can be used to find specific versions of a software title.
- A hot tip was an API endpoint you may not know about: “/JSSCheckConnection”. This behaves like the terminal command.
We were also given a look into the use of “.../subset/basic” which is not documented on all endpoints but can be used to limit the amount of data returned from the server. Doug wrapped up Customer API by sharing a few tips such as POST using an ID of zero and it will return the new ID chosen for that record. He also reminded us to use advanced searches to limit the size of the data sets and therefore the strain on the server when working with API calls.
Next on the agenda was Events API, Doug explained where you can write up some java code that listens for and reacts to different events that are occurring in your JSS. There are 23 different events that the JSS can listen for within the context of Tomcat. One real world example Doug gave was reporting new device check-in information to a third party asset management software in real-time. We were shown a chart with the Events API and 20 of those Events API endpoints have a companion Webhook.
Now, What are Webhooks? Well, Brad Becker took the stage to tackle that very topic.
He began by explaining that they were introduced in August 2016 with version 9.93 and are essentially HTTP callbacks that are usually triggered by an event, while they have no standard defined, they are super easy to implement. Once you have a listener setup to receive the XML or JSON triggered by an event and take action you are ready to use Webhooks.
“…how do we actually configure a Webhook in the JSS? Its super easy, we have a section for them.”
There are three components to a Webhook: The URL with port, content type choice and the actual event type. The advantages of Webhooks are that they are simple, immediate, targeted specific to an event and flexible. Brad explains that a use case would be to use a chat client to notify users of a change in the JSS directly into your chat client using Webhooks. ServiceNow is a currently used real world use case and Jamf has been using ServiceNow integration internally for the past 3 months.
Tool 3rd party software Postman
Tool 3rd party software Insomnia
Finally, Tani Kawleit closed the session by showing off Jamf’s new Universal API. They have written the new Universal API to be modern and RESTful and expands on the existing customer API. It features token-based authentication and uses versioning while supporting pagination and sorting. Tani explained that the universal API uses only JSON for all operations and does not support XML and the payloads are lighter and contain the entire schema for easy reading.
9.93 and later versions of Jamf software already have this built in. This is a very new and exciting feature for which the team is encouraging user feedback. Full documentation can be found at https://.com:8443/uapi/doc.