Set the cover image of a brand template

Uploads the photograph the 'image' front cover of a brand template draws, or removes the one it carries.

THE FILE TRAVELS BASE64 ENCODED and is at most 716800 decoded bytes and 25000000 pixels, and it is JPEG OR PNG ONLY: a GIF is refused with details.reason format_not_supported, which is what the upload of the application accepts too. That refusal has ONE shape whichever half of the body gives the file away -- a name ending in .gif is refused on the spot with the same reason its bytes would have got -- and for everything else the first bytes decide, never the name.

THE FILE IS NORMALISED WHERE POSSIBLE. What is stored is a copy scaled so its longest side is at most 1600 pixels and aiming at 409600 bytes. It is not a guarantee of a size: a file that cannot be decoded, and one whose copy comes out no smaller, is stored exactly as it was sent.

UPLOADING DOES NOT CHANGE THE COVER STYLE: set cover_style 'image' with /v1/brand-templates/update afterwards. Removing the image (file null) is refused with 400 and details.reason cover_image_required while the style is 'image', because that cover would have nothing to draw.

THE PREVIOUS FILE IS NOT KEPT ANYWHERE, so the way back from a replacement is uploading it again; before says only whether there was one.

The brand of the platform, under the empty key, answers 409 NOT_ALLOWED with details.reason system_defined.

if_version is not accepted, and the call is never confirmed.

Refusals: 400 for the framework, the body and the file (details.reason is one of too_large, too_many_pixels, format_not_supported, not_an_image, cover_image_required), 403 WRITE_ACCESS_DISABLED, 404 NOT_FOUND when the template is not this account's, 409 NOT_ALLOWED, 413 when the whole body is over the request ceiling.

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