Skip to main content
Jamf Nation, hosted by Jamf, is a knowledgeable community of Apple-focused admins and Jamf users. Join us in person at the ninth annual Jamf Nation User Conference (JNUC) this November for three days of learning, laughter and IT love.

Please support XML in the new Jamf Pro API

The new Jamf Pro API (currently in beta as of Jamf Pro v10.5) supports JSON only. I would like for it to support XML as well for both producing output and taking input. This makes it easier to work with if you're using bash to interact with it the new Jamf Pro API.

Order by:

Posted: by m.donovan

Since a switch to JSON only would break every tool using the current API that I have please support both.


Posted: by bpavlov

@m.donovan Do note that the new Jamf Pro API is completely different. So you'd have to re-work your tools either way I imagine.


Posted: by mm2270

Oh good grief! Are they really doing this? Why is the Jamf API changing so drastically with 10.5? I swear I'm about ready to give up on Jamf sometimes. I have dozens of scripts, EAs and other items that use the API in bash scripts that expect XML, and it sounds like they are all going to break. Gee, thanks! Why is Jamf doing this exactly?


Posted: by bpavlov

Just to elaborate, the reason for wanting XML is that bash is one of the more basic scripting languages that's commonly used by Mac admins and comes in macOS natively. It handles XML much better natively than it does JSON. Of course, Python is another popular language that can interact with JSON (which is great that you guys added support for JSON for those people). But that leaves out admins who haven't learned Python.


Posted: by mm2270

But that leaves out admins who haven't learned Python.

it certainly does! Like yours truly. Yeah, yeah, I should learn python, but snubbing bash users doesn't seem cool. I cannot understand why they would be ditching xml in the new API. Makes no sense to me. It's like they have taken the FR to support JSON to an extreme, and are going in the opposite direction, which is exactly NOT what was requested. No-one asked for Jamf to drop XML support in favor of JSON, just that JSON should be equally as supported as XML is.


Posted: by prbsparx

@mm2270 they're supporting both APIs for a time. The existing, "Classic API" is old and I my opinion, was architected poorly (doesn't support API tokens)

Your existing scripts will continue to work with the classic API, but you may want to move stuff over to the new as you can since new features and performance enhancements will be added to the new API.


Posted: by crystallized

Chiming in as well on bash scripts that expect XML. I recognize that some of these scripts will have to change slightly anyway to make new calls to new API endpoints, but there's a drastic difference between changing the calls in a script and making little tweaks, and rewriting in an entirely new programming language or writing a ton of extra code to parse the JSON nicely. By forcing use of JSON in the API, Jamf is basically saying that all API scripts need to be written in Python or some other language. So now we need bash for extension attributes or scripts that run on machines, because you're not going to write an extension attribute that uses macOS terminal commands using python because that's some extreme overkill, and python for scripts that interact with the API, and if you want to combine them you have to do some serious overkill somewhere.

This change is going to result in a lot of extra effort and stress. Additionally, I'm curious as to how the Jamf 200, 300, and 400 courses will change to reflect the need to use JSON and Python with the API - I took the 200 very recently and we were taught the Jamf binary terminal commands and shown how to use those in a bash script. Are we now going to be told in these courses that, oh, you can use a bash script from a fresh Mac for this stuff with Jamf but not this other stuff with Jamf? Seems weird.


Posted: by bpavlov

@rviniar That's a good point. For certification purposes, if it requires or needs you to use the API to accomplish certain tasks, then you definitely will need to know Python going into the course (or another language that can interact with JSON natively).


Posted: by rtrouton

I would also like to get XML output in addition to JSON. There just aren’t good ways which are built into macOS which allow Bash to work with JSON output.


Posted: by chris.kemp

+1 for XML, we're planning a data delivery to another system and XML would be preferred.

Waiting to hear someone from jamf chime in, though - focusing on one thing at a time doesn't necessarily mean it's not in their plans. Surely they are aware that eliminating XML would screw up a lot of existing workflows.


Posted: by mhrono

I'll drop in another vote for this. I have a large number of scripts that leverage the API heavily, and use XML to do so. Removing that functionality will require tens of hours of rework and testing. I'm onboard with updating workflows to support new functionality, but removing base functionality your users have relied on for years is not an appropriate way to drive the platform forward. Shame on jamf for this.


Posted: by ChrisL

As the author of ruby-jss and someone who's been working deeply with the 'classic' API since it was originally created, I encourage the switch to full JSON and the dropping of XML.

Here's why:

1) As has been mentioned in the thread, the new API (a.k.a. Universal API) is a very different beast from the original. It is not a change to the original, it is something fundamentally different. Even if they kept XML, existing scripts will have to be re-written to migrate to the new API.

2) JSON has become the de-facto standard for data interchange in http-based REST APIs. Pretty much every programming and scripting language has libraries or tools for working with JSON. This includes bash!! You do not have to learn python or ruby to use JSON. (Thought learning them is very worth your time, see below) There is a tool available for bash called 'jq' (see the PS below)

3) The reason JSON has become such a standard over XML, is that it's far simpler to work with for this kind of data manipulation. It's also smaller, faster, and more human-readable.

4) The current API's use of both XML and JSON has been the source of many bugs and other problems - often the data in the two formats don't match, or data types are incorrect in one or the other. These bugs have gotten worse since Jamf Pro 10 (yes, I've reported all that I have found). Jamf should support one format, and support it well, and given the above points, it should be JSON.

5) If you use one of the JSS API wrapper libraries, you don't have to care about the data format used by the API itself. Currently there is no such library for bash, so you'd have to learn a little about ruby, python, or swift. Doing so would be very worth your time and effort.

(And if you can't or won't step outside of bash, then maybe you could start writing an open-source wrapper library in bash using jq?)

Notice how much XML -or- JSON is used in creating this simple Policy via ruby-jss:
Also notice how readable it is compared to doing the same thing in bash.

require 'jss'
JSS.api.connect server: '', user: 'jssuser', pw: :prompt
my_policy = JSS::Policy.make name: 'Some App'
my_policy.add_package 'some app installer.pkg', action: :install
my_policy.add_script '', priority: :before, parameter4: 'pre-app-install'
my_policy.category = 'Cool Apps'
my_policy.scope.add_inclusion :computer_group, 'early adoptors'
my_policy.scope.add_limitation :network_segments, 'IT users'
my_policy.scope.add_exclusion :computer_group, 'config lite'
my_policy.add_self_service_category 'Apps for Testing'
my_policy.enable  # must save to the JSS before uploading the icon
my_policy.icon = '/path/to/local/icon/image/file.png'

Behind the scenes, ruby-jss is using both JSON and XML - but everyting would be SO much simpler if it were all JSON.

PS: For an example of using 'jq' in bash to parse JSON from a JSS WebHook, see


Posted: by bpavlov

  1. I don't mind re-writing scripts given enough time. Either way, that's not the problem being raised here or the heart of the feature request.
  2. jq is not natively built into macOS. I don't want to have to rely or worry about deploying or packaging tools to get stuff done. I rely on what comes with the OS. If jq came native with macOS, I wouldn't be bringing this up in fact.
  3. These sound like Jamf issues. Not XML issues.
  4. This is unrelated. There's a lot of things people could spend time learning.

Here's the thing: You can build your API tools using JSON with this new Jamf Pro API. That's great. However, the downsides you pointed out seem to be related to Jamf and their QA process. Not necessarily anything that's inherently wrong with using XML.


Posted: by bash

There is really no reason they can't keep XML in as they can easily determine what to accept/output. The data coming out is in the same data structure regardless of it being XML/JSON.

I'm more than happy about finally getting full JSON support but as folks have mentioned bash scripts and JSON don't work well. Sure you can use something like python to assist but there is not a native binary to help manipulate JSON responses.

Please consider this Jamf, you'll make some angry customers if you kill XML.


Posted: by FrozenWaltDisney

Hopefully this will help if your using bash. Only unfortunate thing is that JSON reports integers without quotes and strings with them (makes sense just annoying to format in bash). This is just a quick example from a larger script, so I apologize for the odd variables.

First I am taking the Jamf ID (no quotes)

Second one I am find the department (quotes)


MACADDRESS=$(networksetup -getmacaddress en0 | awk '{ print $3 }')

## Get JAMF XML (Now JSON)
XML=$( curl -H "Accept:text/xml" -ksu $API_USER:$API_PASS $JSS/JSSResource/computers/macaddress/$MACADDRESS -X GET )

##Find ID
#String to search without quotes result
#Find Position in string
#Find length of search variable
#Start after Tag
#Terminate string Length
IDFPOST=`echo "$STRLNGT + $IDPOSNUM + 10" | bc`
#Grab String and cut excess
ID=`echo ${XML:$IDFPOS:$IDFPOST} | cut -d ',' -f 1`

##Find Department
#String to search with quotes result
#Find Position in string
#Find length of search variable
STRLNGTD=`echo ${#STRD} + 1 | bc`
#Start after Tag
#terminate string length
DPTFPOST=`echo "$STRLNGTD + $DPTPOSNUM + 10" | bc`
#Grab string and cut excess
DEPT=`echo ${XML:$DPTFPOS:$DPTFPOST} | cut -d '"' -f 1`

Edit: Updated to Force XML apparently you can choose to do XML or JSON


Posted: by Hugonaut



Posted: by FrozenWaltDisney

Just updated my post. You can force XML or JSON for your return. Got this from Jamf support. Thanks Mike!

This should force XML: curl -H "Accept: text/xml" -ksu username:password -X GET And this is how to force JSON: curl -H "Accept: application/json" -ksu username:password -X GET

Posted: by franton

I have to strongly disagree with you @ChrisL . As @bpavlov has pointed out, none of this is XML's fault. I've been employed in a multitude of environments where I have to hit the ground running: I simply don't have the time during the job or the time while sourcing the next role to learn a complete new language and all it's own foibles just to do a few basic tasks that I used to be able to do with other tools.

It's possible to do bad JSON things in BASH but it involves downloading and compiling things like jq then deploying to every device. What happens if the deploy fails for x reason? It's introducing extreme points of failure into the system. What happens if the app you're reliant on stops being maintained? Same difference.

Let's look at things from the opposite side: Apple has shown every sign of dropping OSS projects from macOS on the basis of its licensing. Anything GPL3 is gone now. We only have older versions left, and if someone gets the bright idea of retroactively changing the licence? Could happen and you'd have to kiss preinstalled tools bye bye in that event.

Lastly XML is the default format for macOS. All the plists are in that format, the OS controls via profiles are in XML. There's again no good reason to go against what is now generally good OS methods and practice.