Update workspace settings and provider keys

Change the workspace's name, region, model defaults, spend caps and provider keys. Send only what changes.

A provider key sent here is encrypted and stored, and is never returned by any operation. Sending an empty string for one deletes it. The read reports only whether a key is set.

daily_usd_cap and monthly_usd_cap are the budget caps the workspace's own spend is measured against.

Writes are made key by key, so a save here cannot revert a change somebody else made to a different setting at the same moment. The response is the workspace as it now stands, in the same shape the read returns.

Written key-by-key rather than as a blob.

Used to SELECT settings, mutate the whole dict in Python, and write it all back, which meant any key a different writer of this row (the onboarding route's editor-floor PATCH /tenants/me/onboarding, or a concurrent second admin) committed in the gap between this route's read and its write was silently reverted. Reproduced: an admin saving daily_usd_cap erased an editor's onboarding.completed_at mid-wizard, which reopened the onboarding route's one-time deployment_mode gate: 2/60 chained attempts, and 26/30 plain concurrent saves lost the onboarding write outright, no attack involved.

jsonb_set/|| here name the exact keys this route owns (default_model, default_embedding_model, daily_usd_cap, monthly_usd_cap, deployment_mode, and, merged rather than replaced, onboarding) and touch nothing else, so a concurrent writer of a sibling key can never be clobbered regardless of interleaving. This is what makes it correct without a lock: a SELECT ... FOR UPDATE here would only serialise this route against itself, and the two other writers of tenants.settings (this route's own past self, and PUT /workspace/security/allowlist) would still race it.

Tenancy: the request is scoped to one workspace, and the credential presented is what selects it. A caller with no membership in that workspace is refused with 404, which is indistinguishable from a workspace that does not exist.

Authorisation: admin or owner. An editor or viewer receives 403 insufficient_role.

Access: Authorization: Bearer carrying either a realm access token or an API key. A key must hold the tenants:write scope, and the workspace role of the person who owns it must meet the floor above.

Response Body

curl -X PATCH "https://example.com/v1/tenants/me" \  -H "Content-Type: application/json" \  -d '{}'

{}