Follows RFC 7396 JSON Merge Patch rules, but send the body as application/json: a body sent as application/merge-patch+json returns 415. The update propagates in real time. status accepts active, paused, archived or scheduled; the other statuses are produced by the buyers and are read-only. The status is written to each buyer on the deal in turn, after the other fields in the request are applied, so a failure partway can leave the buyers in different states: re-send the same request until it returns 200. An archived deal refuses every edit with a 502, so re-sending will not help; if the request was archiving the deal, read the deal to see whether the archive landed. The 200 reports the status the deal resolved to rather than the one sent; see the Deal lifecycle guide. A deal whose buyers are all on a DSP that manages deal status through its own integration (dv360) rejects status with 400. Read statusSettable on the deal before offering a status change at all: it is false whenever any buyer is on such a DSP, which is broader than the 400, because a deal that mixes one with other buyers accepts status and need not resolve to the value you sent. On a deal with a dv360 buyer the DV360 field requirements apply to the merged result, and adFormat and environments cannot be changed (DV360 fixes them at creation).