Upload a new file version

POST /v1/files/:id/versions

Bitrix24 method: disk.file.uploadVersion. Scope: disk.

An upload by the same author within about five minutes OVERWRITES the last version. Its previous contents will not survive in history. The filename stays unchanged; rename using PATCH /v1/files/:id. Format follows the current filename. Uploads into trash are accepted; meta.inTrash is true. Never automatically retry after a timeout: the outcome is unknown, read the file again.

Body: content is non-empty canonical standard base64; expectedContentGeneration is an optional integer >=0. A mismatch against the pre-read globalContentVersion returns 409 DISK_VERSION_CONFLICT. This is an advisory preflight, NOT atomic CAS: concurrent writes may happen after the read. JSON limit 70 MiB, excess returns 413; large-body admission can return 429 LARGE_BODY_BACKEND_BUSY. An empty Bitrix24 error code returns 422 DISK_FILE_NOT_SAVED with the Bitrix24 message.

curl -X POST -H "X-Api-Key: YOUR_API_KEY" -H "Content-Type: application/json" -d '{"content":"YWJj","expectedContentGeneration":2}' https://vibecode.bitrix24.com/v1/files/7/versions

Response: files projection and meta.joinedIntoPreviousVersion: true when the newest version ID stays the same, false when it changes, null when history is unavailable or history permissions refuse the read; meta.inTrash follows DELETED_TYPE, not deletion date.

Errors: 400 invalid ID or parameters, 401 missing key, 403 missing disk scope or Bitrix24 permission, 404 missing record, 422 Bitrix24 business refusal. READONLY keys can read but cannot upload or restore. On writes, 502 DISK_OUTCOME_UNKNOWN requires reading the file before any retry.