What I originally wanted was just a better web interface. Mine is an AVR 1913, and the web page served by the receiver is kind of slow. The shortcuts came later.

I did indeed look at the requests the browser made when on the receiver's web pages. I also used packet sniffing to see what the Denon app on my phone did.

I then wrote a simple web page that just showed current status, and had big buttons for the three sources I use, and for mute/unmute, and for several volume levels, and used JavaScript on that page to send requests to the receiver.

That's when I learned about CORS. The receiver does not send CORS headers, and browsers take that to mean that scripts running on pages that do not come from the receiver should be blocked from receiving any data back.

For the commands to change source, mute, and volume that was OK. They are simple GET requests with the change as query parameters. They could be done without triggering a CORS preflight check. Whether or not the browser blocked the response didn't matter.

Not so for getting status.

That's when I switched the approach from the web page using JavaScript to talk to the receiver to having it be a form and having the web server talk to the receiver. The web page source looked like this:

  <?php
     ...a bunch of functions to control the receiver

     ...code to process the form and invoke those functions
  ?>
  ...the HTML for the web page

Later when I realized being able to control the receiver from shortcuts would be nice, it was a simple matter to copy the web page source, delete the HTML, replace the form processing with command line processing, and have a command line script for controlling the receiver, and then use the run script via ssh shortcut action to invoke it. It never even occurred to me to consider issuing the commands directly to the receiver from the shortcut.

I just gave it a try, using the "Get Contents of URL" action to GET the URL http://ip_of_receiver/goform/formMainZone_MainZoneXml.xml and it worked. It gives back a blob of XML that includes the data I care about (source, mute, volume).

On my Mac I'd probably handle that by passing the XML off to a script to extract that data. I'm not sure how I'd do it on an iPhone or iPad.

There are commands to get individual data items such as the volume whose results might be easier to deal with, but I'm not sure they can be used from shortcuts. They are POST requests to /appCommand.xml, with the command (or commands if you want to batch commands) in XML in the body. For example to get the volume you post

  <?xml version="1.0" encoding="utf-8"?>
  <tx>
    <cmd id="1">GetVolumeLevel</cmd>
  </tx>

The "Get Contents of URL" action does support POST, but the only options it gives for the post data are JSON, Form, and File. For JSON and Form you give it name/type/value triplets and have no direct control of how the post data is formatted. Maybe file would work to get the XML the receiver wants sent but it probably won't have the right content type. I have no idea if the receiver would be OK with that.