Update a calculated metric

Changes a calculated metric of the account.

IT EMPTIES EVERY CACHED RESULT OF THE ACCOUNT, like /v1/filters/update and for the same reason: every widget that draws the metric was computed with the definition that has just changed. It is expensive on a large account, so do not chain calls of this endpoint. Creating and deleting a metric empty nothing.

It is a PARTIAL write, inside the block of its kind too: what the body does not name is left as it is. type, integration_id and level cannot change -- each kind is stored in columns of its own and the definition names fields of that data view -- and a body that names what the metric already is is accepted, so a read can be replayed.

ONLY is_system_defined STOPS AN UPDATE, which is what the editor of the application looks at and at nothing else: a row that carries the stable signature of a catalogue definition and is not marked as the platform's is edited on both surfaces. A metric the platform ships answers 409 NOT_ALLOWED with details.reason system_defined, decided before anything is written.

The two legacy formats a read may publish, time_millis and text, are kept by an update that does not name format and cannot be written: only the four of the editor are accepted.

The answer carries before with the whole previous definition, which is the body that undoes the call.

if_version is not accepted.

Refusals: 400 for the body and the formula, 403 WRITE_ACCESS_DISABLED, 404 NOT_FOUND, and 409 NOT_ALLOWED for a system one. Nothing is emptied in any of those cases: the cached results go only once the new definition has been stored, and a 500 that could not store it says so with details.dropped_account_cache false.

A definition written through this API is not visible to an application window that is already open: the page has to be reloaded before the same definition is edited there.

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