Several MIM API Endpoints return HTTP 400

[CDe80]

All of these return HTTP 400 {"errcode":400,"errmsg":"request handler failed"}
regardless of request body:

Method	Path
GET	/api/device/pfsense/{id}/api/system
GET	/api/device/pfsense/{id}/api/system/update-info
GET	/api/device/pfsense/{id}/api/system/update-info/settings
GET	/api/device/pfsense/{id}/api/system/subsystem-dirty
POST	/api/device/pfsense/{id}/api/system/apply
POST	/api/device/pfsense/{id}/api/system/apply with body {}
POST	/api/device/pfsense/{id}/api/system/apply with body {"subsystem":"aliases"}
POST	/api/device/pfsense/{id}/api/firewall/filter/reload
POST	/api/device/pfsense/{id}/api/firewall/filter/reload with body {}
POST	/api/device/pfsense/{id}/api/firewall/filter/sync
POST	/api/device/pfsense/{id}/api/firewall/filter/sync with body {}

The same behavior is reproducible both against the controller itself
(device_id = localhost) and against a registered managed instance.

Verified working endpoints (for contrast)

These endpoints on the same proxy prefix work correctly and return valid
data:

Method	Path	Notes
GET	/api/login (actually POST /api/login)	JWT auth
GET	/api/controller	Controller telemetry
GET	/api/mim/devices	Full device list including sys_info
GET	/api/device/pfsense/{id}/api/system/status	Dirty-subsystem map returned inline
GET	/api/device/pfsense/{id}/api/system/firmware	Returns "system does not support firmware upgrade" on Plus
GET	/api/device/pfsense/{id}/api/aliases	Full alias list
PUT	/api/device/pfsense/{id}/api/aliases	Creates alias, idempotent by name
POST	/api/device/pfsense/{id}/api/aliases/{name}	Updates alias
DELETE	/api/device/pfsense/{id}/api/aliases/{name}	Deletes alias

Reproduction (curl)

# 1. Login
TOKEN=$(curl -sk -X POST "https://<controller>:8443/api/login" \
  -H "Content-Type: application/json" \
  -d "{\"username\":\"$(printf admin | base64)\",\"password\":\"$(printf <password> | base64)\"}" \
  | jq -r .token)

# 2. Baseline: GET aliases works -> HTTP 200
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://<controller>:8443/api/device/pfsense/<device_id>/api/aliases"

# 3. Affected: POST system/apply fails with 400
curl -sk -i -X POST -H "Authorization: Bearer $TOKEN" \
  "https://<controller>:8443/api/device/pfsense/<device_id>/api/system/apply"

# Response:
# HTTP/1.1 400 Bad Request
# {"errcode":400,"errmsg":"request handler failed"}

# 4. Affected: GET subsystem-dirty fails identically
curl -sk -i -H "Authorization: Bearer $TOKEN" \
  "https://<controller>:8443/api/device/pfsense/<device_id>/api/system/subsystem-dirty"

# Response: identical 400 body

End-to-end scenario that breaks

A typical MIM-API automation workflow:

1. PUT /api/device/pfsense/{id}/api/aliases — creates a new alias on a
   managed device. Succeeds. Alias lands in config.xml.
2. POST /api/device/pfsense/{id}/api/system/apply — should commit the
   change. Fails with 400.
3. GET /api/device/pfsense/{id}/api/aliases — returns the active
   ruleset, which does not yet include the newly created alias,
   because it is still pending.
4. The alias becomes active only after a human operator clicks
   "Apply Changes" in the managed device's WebGUI manually.

This breaks every automation flow that relies on applying remote
configuration changes via the API (alias rollout, update triggering,
reboot-on-change workflows). The same pattern applies to
POST /system/update, which we haven't yet reached — the prerequisite
GET /system/update-info fails, so we can't see whether the actual
upgrade call would also fail.

[marcosm]

It looks like this is more AI "assistance" since currently there's no system/apply endpoint. You can read the docs at e.g.:
https://netgate.github.io/pfsense-api/#tag/system/operation/ApplyDirtyConfig

For any further discussion please create a new post after verifying the information yourself.