Restore file

POST /v1/files/:id/restore

Restores the object from trash. A live object returns meta.restored: false without a native write. A name collision may rename it: meta.renamedFrom contains the previous name or null.

Parameters

Key scope: disk. No body required.

curl

curl -X POST "https://vibecode.bitrix24.com/v1/files/42/restore" -H "X-Api-Key: YOUR_API_KEY"

JavaScript

const response = await fetch("https://vibecode.bitrix24.com/v1/files/42/restore", {
  method: "POST",
  headers: { "X-Api-Key": "YOUR_API_KEY" },
});
const data = await response.json();

Response

{
  "success": true,
  "data": {
    "id": 42,
    "name": "report.txt",
    "deletedType": 0
  },
  "meta": {
    "restored": true,
    "renamedFrom": null
  }
}

Errors

400 INVALID_ID / INVALID_PARAMS; 401 TOKEN_MISSING; 403 SCOPE_DENIED / BITRIX_ACCESS_DENIED / WRITE_BLOCKED_READONLY_KEY; 404 ENTITY_NOT_FOUND; 422 BITRIX_ERROR / DISK_RESTORE_REFUSED; 429; 502 DISK_OUTCOME_UNKNOWN / BITRIX_UNAVAILABLE; 503.

A READONLY key cannot perform this action. A missing object returns 404. Restoring an already live object again returns 200 with meta.restored: false.

Known behavior

Also restores parent folders from trash. An existing public file link becomes accessible again. Restoration after purge is impossible. Trashed files are absent from ordinary folder listings: keep the id from your DELETE or read GET /v1/files/:id.

Only deletedType != 0 indicates trash: deletedAt and deletedBy are not cleared after restoration. Writes are never automatically retried. A network interruption leaves the outcome unknown: read the object before retrying. Batch does not support these dedicated actions.

Bitrix24: disk.file.restore.

See also

• DELETE
• Purge