# list_storage_backups

Source: https://modulify.ai/docs/api/backups/list-storage-backups

Lists the archives taken of a site's file storage, newest first, with the state of each and the site's manual backup allowance.

- Title: List storage backups
- Scope: `sites:read`
- Access: Read only
- Endpoint: `POST /v1/list_storage_backups`

These are the archives the **Storage** tab of [Backups](https://modulify.ai/docs/editor/backups#storage-backups) lists. Each one is a `.zip` of the whole bucket, public and private files alike, kept outside that bucket so it never counts toward the site's storage usage. A row carries its `_id`, its name, who took it, when, how large the archive is, how large the files it covers were and how many there are.

A row typed `manual` was taken deliberately. `automatic` is the daily archive the platform takes on a paid plan, only while daily storage backups are on for the site and only on a day the files actually changed. `restore` is the **Before restore** backup taken of the whole storage right before a restore overwrote or deleted files, so restoring it reverses that restore. A row reads `pending` while it is still being archived, `ready` once it is finished, and `failed` with the reason beside it when it stopped.

The response also carries the manual allowance in `quota`, as `limit`, `used` and `remaining`, the total `count`, and `dailyEnabled`, which is false when daily storage backups were turned off with `set_storage_backup_schedule`. `canBackup` is false both on a workspace without a paid plan and when the plan could not be confirmed, which `planUnknown` tells apart. When `planUnknown` is true, the tool tells the client to say your plan could not be confirmed and nothing about upgrading, because `create_storage_backup` is refused for that same reason until it can be.

Use a row's `_id` as the `backupId` for `delete_storage_backup`, `browse_storage_backup`, `read_storage_backup_file` and `restore_storage_backup`. A finished backup can be browsed, read one text file at a time and restored with an access token, over MCP or the [HTTP API](https://modulify.ai/docs/api), but downloading a backup, or a file out of one, happens only in the editor. A backup taken in an older format can be neither browsed nor restored, only downloaded.

Older archives are thinned as they age, and nothing survives past 1 year except the newest finished one, so an archive from long ago may simply not be there. It returns 10 per page, so pass `page` to go further back.

## Request

Call it with a `POST` to `https://api.modulify.ai/v1/list_storage_backups`, sending the inputs below as a JSON object. The token needs the `sites:read` scope.

It only reads and changes nothing, so retrying it is safe.

```bash
curl -X POST https://api.modulify.ai/v1/list_storage_backups \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"projectId":"PROJECT_ID"}'
```

Over MCP, the same method is the [list_storage_backups tool](https://modulify.ai/docs/mcp/backups/list-storage-backups).

## Inputs

| Input | Type | Required | Description |
| --- | --- | --- | --- |
| `projectId` | string | Yes | The site id, from `list_sites`. |
| `page` | integer | No | Which page of the list to read, starting at 1. Defaults to 1. |

## Response

Every call answers with the [JSON envelope](https://modulify.ai/docs/api/requests-and-responses#the-response) of `success`, `message`, `data`, `code` and `version`. `data` holds the result described above, and on a method that returns a total, `count` carries it. The [response headers](https://modulify.ai/docs/api/requests-and-responses#headers-on-every-method-call) carry the call's `X-Request-Id` and what is left of your per-minute budget in `X-RateLimit-Limit`, `X-RateLimit-Remaining` and `X-RateLimit-Reset`. [Errors](https://modulify.ai/docs/api/errors) explains every status code a call can answer with.