NOTE: There are two critical differences between Unifi controllers and the UDM Pro's API:

• The login endpoint is /api/auth/login
• All API endpoints need to be prefixed with /proxy/network (e.g. https://192.168.0.1/proxy/network/api/s/default/self)

These are REST calls that can be made without a site context. I do not believe any updates ( PUT ) can be called on these endpoints.

 { "data" : [ ] , "meta" : { "rc" : "ok" , "server_version" : "5.7.23" , "up" : true , "uuid" : "0e727580-ffff-ffff-ffff-403dcd5a7bd4"}}  

All commands are presumed to be prefixed with api/s/{site}

Posting to the endpoint api/s/{site}/cmd/<manager> with the json {"cmd": "command"} you can invoke commands on the controller.

This data was extracted from the javascript of the site.

There are 2,213 named applications in the javascript dynamic.dpi.js. See extracted cat_app.json to include for lookups and example usage.

The application id is a compound id using bitwise shift left on the category id + application id sent from the api using list_dpi_stats_filtered

function compoundId($cat, $app){
  return (intval($cat) << 16) + intval($app);
}

Dump of found endpoints waiting for documentation

# logged in user
api/s/{site}/self

# Country codes
api/s/{site}/stat/ccode
# Availible WiFi channels
api/s/{site}/stat/current-channel

# Dashboard health
api/s/{site}/stat/health

# Active client devices
api/s/{site}/stat/sta
# Configured clients
api/s/{site}/stat/user

# Devices
api/s/{site}/stat/device-basic - mac, type
api/s/{site}/stat/device - can be filtered with macs: [ ..., ... ]

# Detailed site settings
api/s/{site}/stat/sysinfo

# /rest/ endpoints also have a /cnt/ which returns the count for the data portion
# can be used for any but seems targeted towards alarms

# Site settings
api/s/{site}/rest/setting - this is a big one with a weird mechanism for updating

# Firewall rules
api/s/{site}/rest/firewallrule - only lists user-defined rules

# Firewall groups
api/s/{site}/rest/firewallgroup

# routes
api/s/{site}/rest/routing

# Alarms
# List of alarms
api/s/{site}/rest/alarm
# list of unarchived alarms
api/s/{site}/rest/alarm?archived=false

# User groups - bandwith settings
api/s/{site}/rest/usergroup

# ?
api/s/{site}/rest/wlangroup

# Wireless networks
api/s/{site}/rest/wlanconf

# ?
api/s/{site}/rest/tag

# Site networks
api/s/{site}/rest/networkconf

# example backup path
dl/autobackup/autobackup_5.7.23_20180513_0000_1526169600008.unf

# Insights - sessions
api/s/{site}/stat/session?type=all&start=1526515200&end=1526688000

# Insights - EDU streams
api/s/{site}/stat/stream

# Switch port conf?
api/s/{site}/rest/portconf

# Configured port forwards and uPNP - transfer bytes is listed but doesn't appear populated
api/s/{site}/stat/portforward


# Possible list of all callable managers
system
devmgr
stamgr
evtmgr
cfgmgr
hotspot
sitemgr
streammgr
backup
throughput
stat
firmware
firewall
elite

This may apply to other configurations, but initial testing shows that port forward rules can be enabled/disabled using PUT against the endpoint /api/s/{site}/rest/portforward/{rule-id} with a body such as:

{
    "enabled": true
}

The rule ID can be retrieved using the above described port forwarding GET request and is found in the "_id" key.

New rules can be created using POST, but be aware that there seems to be very little validation (it's possible to create entries with no information other than the fact that they're enabled, for example).