Create Re-upload Intent
Phase 1 of a re-upload: mint a NEW version of an existing file. Identical
to a first-version upload intent from the client’s perspective — declare
the new bytes (name, MIME type, exact byte size) and receive a short-lived
signed uploadUrl pinned to the declared content type and byte size.
To complete the re-upload:
PUTthe raw bytes touploadUrlwith the two signed headers (Content-Type: <the contentType you declared>andx-goog-content-length-range: <byteSize>,<byteSize>). Bytes go straight to cloud storage — never through this API.POST /files/{fileId}/finalizewith the returnedversionId— the SAME finalize endpoint first uploads use. Finalize flips the new versionreadyand repoints the file at it, so the new bytes silently become current. The file keeps its id, placements, categories, and full history.
Because a re-upload changes an existing file, it is gated by
company.file:update — not company.file:create.
Required permission: company.file:update
Authorizations
API key authentication. Send your raw API key as the Authorization header value with NO scheme prefix — Authorization: YOUR-API-KEY. Do NOT prefix it with Bearer or ApiKey, and do not use an X-API-Key header; those are not accepted.
Path Parameters
Company identifier
File identifier
