i think i might be wrong but i believe it is possible with the API - after a quick look - I have personally never done this but if you navigate to <yourjssurl:8443>/api/#!/packages

threw this together in about 3 minutes - NO IDEA IF IT WORKS BUT THIS IS THE JIIST - will test & update during freetime throughout the day. In theory - the api will get the package, download it to a location on your computer & the the installer flag will install it.

somebody correct this I'm not an API guru but I know im close lol

#!/bin/bash

apiuser="userhere"
apipass="passhere"

jssURL=$( /usr/bin/defaults read /Library/Preferences/com.jamfsoftware.jamf jss_url )
jssAPI="${jssURL}JSSResource/packages/id/"
jsscURL="--silent"
jssoutput="/PathHere"

/usr/bin/curl ${jssCURL} --output "${jssoutput}" --request GET --user "${apiuser}":"${apipass}" 
  "${jssAPI}PackageID"

installer -target / -pkg $jssoutput

@Hugonaut, Thanks for the input. This API way is interesting and I didn't even think of pursuing it this way. The only thing that concerns me using this method is it requires a username and password in plain text within the script for the API account. Do you (or anyone) know what happens to a script if I were to add it as part of a policy? It must get copied to the target computer somewhere first before it is run. Theoretically, I could install multiple packages using this method (if it works) by simply adding more <id>'s in the script. I could also make the username and password outside of the script when setting up the script payload by the use of the parameter fields. This would accomplish two things- get the username/password out of plain site within the script and minimize the creation of a bunch of policies.

@joethedsa @Hugonaut's production version would probably use this method:

apiuser="$4"
apipass="$5"

This would allow you to use the parameter 4 and 5 fields in the script payload of the policy as the placeholder for user/pass.

@ryan.ball, thanks!

I don't believe you can pull down the actual packages with the API. The /JSSResource/packages/ resource is for pulling down the XML details on the package, such as the ID, display name, file name, priority, OS requirements, whether FEU or FUT were enabled and so on. I don't see anything in the output that let's you pull down the package itself, because the package is not stored directly in the database. It's on a distribution point, whether a cloud one or local.
There are hash_type and hash_value keys in the xml, but I don't think it's possible to use those. I've never tried using that though.

I don't believe you can pull down the actual packages with the API.

i do believe you are correct & this is in fact the case @mm2270 after reading a bit more into it - i don't believe its possible - hence the "I think I might be wrong" intro lol

@Hugonaut and @mm2270, I think that I was over complicating things. I was forgetting that you can have multiple packages within the packages payload of a policy. Therefore, Jamf sort of already has what I was hoping to do which is to minimize the amount of policies that I have to create so there isn't so much clutter. If / when I have multiple packages in one payload, there is that slight chance that things can go wrong so I'll need to look at each payload carefully to isolate potential problems. Thanks for all the input!

personally I like to keep all my actual installs as separate policies and have a trigger to run them like install-myapp-live or install-myapp-test meaning only one policy ever needs to be updated for a new version.
then in the policies that call the installer i use this script which means I can run several from the one script. If I wanted to I could chain them by having one policy call another that has multiple polices in it as well, never had to do that though.
You simply add the script to jamf then add it to any install policies and set variables for each trigger required.
Always worked faultlessly for me.

#!/bin/bash

####################################################################################

script to take multiple inputs and use them to fire multiple jamf policy -event triggers.

uses $4--11

script will exit out when it detects no more policies to try #

Mark Lamont July 2018

####################################################################################

###############################

if 8 aren't enough what are you doing!?

###############################

policyTrigger1="${4}" policyTrigger2="${5}" policyTrigger3="${6}" policyTrigger4="${7}" policyTrigger5="${8}" policyTrigger6="${9}" policyTrigger7="${10}" policyTrigger8="${11}"

####

debug lines.

####

echo "$policyTrigger1"

echo "$policyTrigger2"

echo "$policyTrigger3"

echo "$policyTrigger4"

echo "$policyTrigger5"

echo "$policyTrigger6"

echo "$policyTrigger7"

echo "$policyTrigger8"

################

run sequentially.

when no input found exit

################

if [ "$policyTrigger1" != "" ]; then jamf policy -event $policyTrigger1 else echo "No work to do at all!" exit 0 fi if [ "$policyTrigger2" != "" ]; then jamf policy -event $policyTrigger2 else echo "no more work to do" exit 0 fi if [ "$policyTrigger3" != "" ]; then jamf policy -event $policyTrigger3 else echo "no more work to do" exit 0 fi if [ "$policyTrigger4" != "" ]; then jamf policy -event $policyTrigger4 else echo "no more work to do" exit 0 fi if [ "$policyTrigger5" != "" ]; then jamf policy -event $policyTrigger5 else echo "no more work to do" exit 0 fi if [ "$policyTrigger6" != "" ]; then jamf policy -event $policyTrigger6 else echo "no more work to do" exit 0 fi if [ "$policyTrigger7" != "" ]; then jamf policy -event $policyTrigger7 else echo "no more work to do" exit 0 fi if [ "$policyTrigger8" != "" ]; then jamf policy -event $policyTrigger8 else echo "no more work to do" exit 0 fi echo "all 8 policies triggered, good work everyone!" exit 0