Change a project's settings
Changes only the settings you send. A key you omit keeps its stored value, so send the keys you mean to change and nothing else — this is a merge patch, not a replacement. Nested settings are sent nested ({"greetingsSettings": {"staticGreeting": "Oi!"}}), which changes that one greeting and leaves the rest of the section alone. Read getProjectSettings first: the keys it returns to you are the keys accepted here, and anything else — a field your role cannot write, or a key that is not a setting at all — is refused by name with nothing saved. Every accepted call is recorded in getProjectSettingsHistory with the value on each side of the change, which is what makes it reversible.
Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Headers
The CloudChat instance the account lives in, e.g. 4. Sent as a header, and required: with accountId it forms the pair that names exactly one account, which accountId alone does not. listMyCloudChatAccounts returns the value to send here alongside each accountId.
Path Parameters
The ClaudIA project to act on, by name. Get the names from listMyClaudiaProjects — a project these credentials do not cover answers 404, indistinguishable from one that does not exist.
Query Parameters
The CloudChat account whose permissions decide what you may read and write here, e.g. 7. It is permission context, not the resource: the project is named in the path. Only unique within an instance, so it is always read together with the cloudchat-instance header — get the pair from listMyCloudChatAccounts. An account your credentials hold no editing claim for answers 403.
Body
Response
Saved. The settings are returned as they now stand, filtered the same way getProjectSettings filters them.
How one ClaudIA project behaves — the same settings the ClaudIA app shows on its settings screens. The set of keys is NOT fixed: it is whatever your role is allowed to see on this account, resolved against CloudChat on every call, so two callers reading the same project can legitimately get different keys. Read this before patching: the keys present here, minus the ones listed in readOnlyPaths, are exactly the keys updateProjectSettings accepts from you. Nested settings arrive as nested objects, and a key is addressed in readOnlyPaths, in the history and in an error as its dotted path (greetingsSettings.staticGreeting).
The project these settings belong to. Always present, whatever your permissions.
"acme_support"
Dotted paths present in this response that you may read but not write. Sending one of them to updateProjectSettings is refused. Absent when there are none.
Dotted paths present in this response that you may read but not write. Sending one of them to updateProjectSettings is refused. Absent when there are none.