Changes the fields of a report that already exists, the period of every one of its sections and the whole settings window of the report. It is a partial update: only the fields the body carries are written, and inside a block only the keys it carries, so everything it leaves out is left exactly as it is. /v1/reports/get publishes the same settings under settings, key by key, which is the object this call takes back.

date_range is not a field of the report: the period belongs to each SECTION, and what this field does is what the application's own button does, applying one range to ALL of them at once. It writes the range and nothing else, so the header of each section goes on showing whatever it showed. The answer lists the sections it wrote, and the cached results of the whole report are dropped so the next read is of the new period.

data_sources rebinds the report as a whole and is for the reports whose report_level_data_sources is true. On a report that binds a connection per widget it is refused with 400 APPEND_NOT_ALLOWED and reason per_widget_data_sources; those are rebound with /v1/reports/set-connections.

share is the public link of the report. The id is minted by the call the first time the report is shared and again whenever regenerate is true, which invalidates the previous link; a password is stored hashed and null empties it. A template has no public link and the field is refused on one.

The settings window is the rest of the body. brand_template and language_file take an empty string for the system one. A template carries no brand of its own: on one brand_template takes only the empty string, and the key a template still stores is accepted and changes nothing. front_cover carries the type, the texts and the date line, and the TYPE commands the file: a type that prints an uploaded PDF is refused on a report that carries none, and a type that prints none removes the file the report carried, which the answer says with a COVER_FILE_REMOVED warning -- a dry run says it too -- and before.front_cover.file. localization either follows the account or belongs to the report: the six settings under it exist only in the second case, sending one of them with use: account is refused, and a call that writes that branch asks for the six together. ai_brief has three states: absent keeps it, an empty string removes it, a text replaces it.

The block /v1/reports/get answers under settings is this body, whole: sending it back writes what the report already has and changes nothing. A key carrying null means the column has no value and is left as it is; an empty string is a value. The three keys only a read can answer -- brand_template_name, language_file_name and front_cover.file -- are accepted and ignored, each with a READ_ONLY_FIELD_IGNORED warning naming it. updated_fields and before carry the fields the call really wrote, so a block that changes nothing appears in neither.

Changing the language file, the localization mode or the date format drops the cached results of the report so the next read is of the new setting; nothing else drops them, and nothing is executed by this call.

The uploaded PDF of the cover is the one thing of that window this call does not write: it is a file, and it has a route of its own, /v1/reports/set-cover-file, which writes the cover type with it.

What it never writes: the level at which the report binds its data sources (moving a report to per widget bindings deletes its binding rows), its identity, structure and provenance, and the settings of the ACCOUNT.

There is no guard against concurrent edits: the call writes over whatever the report holds when it lands, a change made in the application since the client read the report included.

Refusals: 400 for the framework and the body, 400 APPEND_NOT_ALLOWED with reason per_widget_data_sources or template_based, 403 WRITE_ACCESS_DISABLED, 404 NOT_FOUND and 409 REPORT_IN_TRASH.

Every write endpoint reads dry_run and idempotency_key; see the Write guarantees section of the introduction.