# list_database_backups

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

Lists the archives taken of a site's database, newest first, with the state of each and whether the site can be backed up at all.

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

These are the archives the **Database** tab of [Backups](https://modulify.ai/docs/editor/backups#database-backups) lists. Each one is a `.zip` holding `database.sql`, a plain SQL dump of every table and every row. A row carries its `_id`, its name, who took it, when, how large the archive is, how large the database was and how many tables and rows it held.

A row typed `manual` was taken deliberately, and `automatic` is the daily backup the platform takes on a paid plan, only while daily database backups are on for the site and only on a day the data actually changed. A row reads `pending` while it is still being exported, `ready` once it is finished, and `failed` with the reason beside it when it stopped.

`eligibility` reads `ready` when the site can be backed up at all, `unsupported` when the site is not on the newer database, and `no-database` when it has no database yet. On anything but `ready` no backup can be taken and none will ever appear. `canBackup` is false whenever `eligibility` is not `ready`, and also when the workspace is not on a paid plan or the plan could not be confirmed, so read `eligibility` first and treat `canBackup` as an answer about the plan only while `eligibility` reads `ready`.

`planUnknown` tells those last two apart: when it is true, the tool tells the client to say your plan could not be confirmed and nothing about upgrading, because `create_database_backup` is refused for that same reason until it can be. The response also carries the manual allowance in `quota`, as `limit`, `used` and `remaining`, counted apart from storage backups, the total `count`, and `dailyEnabled`, which is false when daily database backups were turned off with `set_database_backup_schedule`.

Use a row's `_id` as the `backupId` for `delete_database_backup`, and pass `page` to go further back, since it returns 10 per page. A database backup has nothing to browse and cannot be restored, through MCP, the [HTTP API](https://modulify.ai/docs/api) or by anyone: rows come back only when you download the archive in the editor and put the data back deliberately. Older archives are thinned as they age, and nothing survives past 1 year except the newest finished one.

## Request

Call it with a `POST` to `https://api.modulify.ai/v1/list_database_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_database_backups \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"projectId":"PROJECT_ID"}'
```

Over MCP, the same method is the [list_database_backups tool](https://modulify.ai/docs/mcp/backups/list-database-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.