Changes settings, and applies them.
Why the change is tried before it is stored
A value this binary will not accept is refused here, with the key named, instead of written and quietly dropped at the next start-up. The start-up fallback exists so a bad row cannot make an instance unbootable: a safety net, not the validation path, and letting the panel lean on it would mean a save that reports success and reverts on restart.
Why one request can carry several
Settings that only make sense together, such as turning the access log on and setting its retention, should not have a moment where one is applied and the other is not. They are validated as a set and stored only if the set loads.
Errors
400 for an unknown key, one that cannot be changed, or a value the
configuration will not accept. 401, 403 and 404 as for [list].
sessiontessera_session<token>Set by POST /auth/login. A browser sends it automatically; it is HttpOnly, so page scripts cannot read or set it.
application/json- body
Body of PUT /admin/settings.
changes*The changes to apply, by dotted key.
null clears a setting, so it falls back to whichever layer comes next:
the environment, or the default. That is the only way back to a value
the panel did not choose, and why clearing is a value and not a second
endpoint.
confirm?booleanGo ahead even though the change destroys something.
Without it, a change that would remove things is refused and the answer says what and how many. Two round trips by design: an empty "are you sure?" is a button everyone clicks, and a number gives pause.
Every setting, as it now stands
application/json- response
Everything this instance can be configured with.
settings*array<>Every setting, editable or not.
curl -X PUT 'https://example.com/api/v1/admin/settings' \ -H 'Content-Type: application/json' \ -d '{ "changes": {}}'{ "settings": [ { "editable": true, "fallback": {}, "key": "string", "refusal": "string", "secret": true, "source": "default", "value": {} } ]}