Copy a section into another report

Copies one section of a report, with every widget in it, into ANOTHER report of the same account, and raises the version of the target report's sections structure.

THE COPY IS RE-BOUND TO THE REPORT IT LANDS IN. Every widget of it follows the way the TARGET binds its data sources: in a report with a report level binding each widget reads the target's connection for its integration, and in a report that binds a connection per widget the copies arrive with none and are pointed at one with /v1/widgets/set-connection or /v1/reports/set-connections. That re-binding is the whole reason the source and the target have to be two different reports: run inside one it would clear the connections the widgets already have. To copy a section where it already is, use /v1/sections/duplicate.

The copy lands at the END of the target report, named after the original with the copy suffix of the account's language (trimmed to the 80 characters a section name takes: the suffix is kept whole and the title gives way), and the client briefs of its AI widgets travel with it.

IT NEVER CROSSES ACCOUNTS: both reports are the caller's own. Neither end can be a report built on a template -- the target has no sections of its own to receive one, and the ones a derived report shows belong to its template (400 APPEND_NOT_ALLOWED, reason template_based).

AN AI SUMMARY INSIDE THE SECTION KEEPS WHAT TRAVELS WITH IT and loses the rest: the widgets copied beside it and the section itself are re-pointed at their copies, and any key that named a section or a widget of the report it came from is dropped, because in the target it names nothing. lost_selections enumerates them, so the summary can be pointed at something again.

Refusals: 400 for the framework and the body, 400 INVALID_VALUE, 400 APPEND_NOT_ALLOWED, 403 WRITE_ACCESS_DISABLED, 404 NOT_FOUND, 409 VERSION_MISMATCH and 409 REPORT_IN_TRASH.

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