Restore a report from the trash

Takes a report out of the trash and gives it back the type it had before /v1/reports/delete put it there, so it shows up again in its listing and counts against the plan again. /v1/reports/trash lists what can be restored and until when. Because a report in the trash does not count against the plan, the account may have filled that room since: a restore that does not fit is refused with 403 PLAN_LIMIT_REACHED. A report that is not in the trash is refused with 409 REPORT_NOT_IN_TRASH. The scheduled deliveries the report had were deleted when it went to the trash and are NOT recreated: create them again with /v1/schedules/create. This endpoint never asks for a confirmation: it only adds a report back. A retry with the same idempotency_key answers the original call even if the report changed state in between; read /v1/reports/get for its current state. Refusals: 400 for the framework and the body, 403 WRITE_ACCESS_DISABLED or PLAN_LIMIT_REACHED, 404 NOT_FOUND, 409 REPORT_NOT_IN_TRASH plus the idempotency conflicts. if_version is not accepted: a restore does not change the structure of the report.

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