We are using it and are encouraged by the results. What questions do you have?

For Apple Silicon Macs, you need either script user credentials that have boot volume ownership, or use API commands in a script so that MDM Commands push the updates.  The API credentials in JAMF Pro need the following Permissions: "Computers Create", " Compuers Read", and "Send Computer Remote Command
to Download and Install macOS Update".

You can encrypt those credentials in a script.  The deferral and deadline options need to be read through a few times to suit your environment.

I have a policy that caches super, then runs the following script.  In this example, I left a default of 3 deferrals.

"#!/bin/bash

function superSilicon () {
APIUSER="JAMF_APIUSER"
pword="Encrypted_JAMF_APIPASSWORD"
/Library/Management/super/super --jamf-account $APIUSER --jamf-password $pword --count-deadline 3
}

function superIntel () {
/Library/Management/super/super --count-deadline 3
}

function superbyProcessor () {
# Check to see if Intel or Apple Silicon
processor=$(/usr/bin/arch)
if [ "$processor" = "i386" ]; then
superIntel
elif [ "$processor" = "arm64" ]; then
superSilicon
fi
}

# Run SUPER if installed
if [ -f "/Library/Management/super/super" ] ; then
superbyProcessor
else /usr/local/bin/jamf install -package super.pkg -path /Library/Application\\ Support/JAMF/Waiting\\ Room/ -target "/"
superbyProcessor
fi"

We plan on using the API for both and seem to have to set up, how is it you are triggering it? 
and what was your way of deploying?

For testing I trigger it with a monthly check in using execute command /super however this will prompt the users regardless of pending updates or not.

Thank you 

Once install onto a Mac how is it triggered is it a manual process each time you want to update?

do you have any recommendations on best practices to make it as foolproof as possible? 

Thanks

Currently, yes, we trigger it via a policy that we update monthly to meet the deadlines that we have for compliance. 
Kevin, the developer, is working on version 2.0 now and he hopes to have a daily run companion part.
As for the API part, creating a user with a very narrow permission set does the trick for us. When we don't have a mandatory update policy running we can disable that user or change the password and it is neutered. 

For Apple Silicon Macs, you need either script user credentials that have boot volume ownership, or use API commands in a script so that MDM Commands push the updates.  The API credentials in JAMF Pro need the following Permissions: "Computers Create", " Compuers Read", and "Send Computer Remote Command
to Download and Install macOS Update".

You can encrypt those credentials in a script.  The deferral and deadline options need to be read through a few times to suit your environment.

I have a policy that caches super, then runs the following script.  In this example, I left a default of 3 deferrals.

"#!/bin/bash

function superSilicon () {
APIUSER="JAMF_APIUSER"
pword="Encrypted_JAMF_APIPASSWORD"
/Library/Management/super/super --jamf-account $APIUSER --jamf-password $pword --count-deadline 3
}

function superIntel () {
/Library/Management/super/super --count-deadline 3
}

function superbyProcessor () {
# Check to see if Intel or Apple Silicon
processor=$(/usr/bin/arch)
if [ "$processor" = "i386" ]; then
superIntel
elif [ "$processor" = "arm64" ]; then
superSilicon
fi
}

# Run SUPER if installed
if [ -f "/Library/Management/super/super" ] ; then
superbyProcessor
else /usr/local/bin/jamf install -package super.pkg -path /Library/Application\\ Support/JAMF/Waiting\\ Room/ -target "/"
superbyProcessor
fi"

getting Error: Unrecognized Options: --count-deadline 3