Sign in
plugin

Update plugin, acknowledging a changed privacy disclosure

Same as GET, with a body. When the block the upgrade would land differs materially from the accepted one (see GET /api/plugin/{RepoName}/privacy) the upgrade is refused unless privacyAccepted matches that pending block. The pull fast-forwards to the ref the check just fetched (no second fetch), and the block is recorded as accepted afterwards, from the installed copy, only once the code has landed; if what landed is not what was accepted (a push in between) the record is dropped and the next check asks again.

post/api/plugin/{RepoName}/upgrade

Request body

privacyAcceptedobject nullable

The pending privacy block as shown to the operator, or null to acknowledge that the disclosure was removed.

Response

Plugin upgraded, or refused. Refused on privacy grounds: {"Status": "Error", "Code": "PrivacyMismatch", "Message": "...", "privacyChanged": true, "plugin": "fpp-x", "pending": {...}}, the same shape as POST /api/plugin's refusal; pending is the block to review (null = no disclosure). Streaming (?stream=true) prints the readable ERROR: line only -- no @@PRIVACY-PENDING@@ marker, unlike an install.

Status'OK' | 'Error'
Messagestring
Code'PrivacyMismatch'

Present only on a privacy refusal, so a script can tell it from any other error without parsing Message. The same field on POST /api/plugin and POST /api/plugin/{RepoName}/upgrade.

privacyChangedboolean

true on a privacy refusal.

pluginstring

On a privacy refusal: the plugin (for an install, possibly a dependency plugin) whose block must be reviewed.

pendingobject nullable

On a privacy refusal: the block to review (null = no disclosure); post it back as privacyAccepted to proceed.

Changes