Update organization settings (admin, or manage_org_settings, or deposit_staff_editable)

A true partial update: a key that is not in the body is not in the UPDATE.

This paragraph used to say the opposite, and the opposite used to be true; every field was derived with a fallback, so omitting tagline nulled it, omitting notifyEmailEnabled forced it true, and omitting bookingTheme reset it to light. That was fixed in the route (a has() gate, the same discipline the reservations, appointments and clients PATCH routes use) and the description was not moved with it. scripts/check-hardening.ts asserts the current behaviour column by column.

Three ways in (migration 0082), checked in order of breadth. An admin may write anything below. A staff login granted manage_org_settings may write anything EXCEPT five admin-only keys that either change the org's public identity (slug, status) or grant a permission (depositStaffEditable, unlinkedStaffFullAccess, staffClientVisibility); a permission that can grant permissions is not delegable, it is the thing doing the delegating. Absent that, a staff login may still write the six deposit-policy fields alone, but only once this org's admin has turned on depositStaffEditable (migration 0075).

slug, status and the three admin-only permission flags are written with service-role, because migration 0022 (and 0075 for the deposit flag) leaves those columns out of the tenant column grant; a staff JWT provably could flip them through raw PostgREST before that. Everything else goes through the RLS-scoped client.

business_type is NOT settable. Flipping a live org's vertical strands whatever it already has; a conversion is a data migration, not a settings toggle.

Response BodyCopy Anchor Link

curl -X PATCH "https://example.com/api/companies" \  -H "Content-Type: application/json" \  -d '{    "name": "string",    "slug": "string",    "status": "active"  }'

{  "ok": true}