## Mark as read

`POST /v1/notifications/read`

Marks the recipient's notifications as read or unread. By default it marks the notification with the given `id` and all notifications with a greater identifier.

## Parameters

| Parameter | Type | Required | Description |
|----------|-----|:-----:|---------|
| `format` (query) | string | no | `v2` enables v2 mode — see "v2 mode" below. Any other value is ignored, and the regular response is returned. A repeated `format` is not rejected: the last value wins, so `format=v1&format=v2` enables v2 mode, while `format=v2&format=v1` returns the regular response. The `format[]=v2` form enables v2 mode if all of its values are `v2` |

## Request fields (body)

| Field | Type | Required | Description |
|------|-----|:-----:|---------|
| `id` | number | no | Notification identifier from the [`POST /v1/notifications`](./send.md) response. This notification and all notifications with a greater `id` are marked. Without the `id` field, notification statuses do not change |
| `action` | string | no | `Y` — mark as read, `N` — as unread. Defaults to `Y` |
| `onlyCurrent` | boolean | no | `true` marks only the notification with the given `id`. Otherwise, all notifications with an identifier greater than or equal to `id` are marked |
| `ids` | number[] | no | v2 mode only, where it is required: 1 to 100 positive integer identifiers. An identifier is the `id` field of a notification in the [feed](./list.md) or `notificationId` from the [`POST /v1/notifications`](./send.md) response |

**v2 mode.** `POST /v1/notifications/read?format=v2` marks exactly the notifications in the `ids` list as read. Other notifications, including those with a greater `id`, are not affected, and this mode cannot mark notifications as unread. The mode accepts only the `ids` body field and the `format` query string parameter: the `id`, `action`, `onlyCurrent` fields and any others are rejected with `400 INVALID_PARAMS` before the Bitrix24 call. Instead of `true`, `data` carries the unread counter after the call and the list of marked notifications.

## Examples

### curl — personal key

```bash
curl -X POST "https://vibecode.bitrix24.com/v1/notifications/read" \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "id": 37421, "onlyCurrent": true }'
```

### curl — OAuth application

```bash
curl -X POST "https://vibecode.bitrix24.com/v1/notifications/read" \
  -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "id": 37421, "onlyCurrent": true }'
```

### JavaScript — personal key

```javascript
const res = await fetch('https://vibecode.bitrix24.com/v1/notifications/read', {
  method: 'POST',
  headers: {
    'X-Api-Key': 'YOUR_API_KEY',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ id: 37421, onlyCurrent: true }),
})
```

### JavaScript — OAuth application

```javascript
const res = await fetch('https://vibecode.bitrix24.com/v1/notifications/read', {
  method: 'POST',
  headers: {
    'X-Api-Key': 'YOUR_APP_KEY',
    'Authorization': 'Bearer USER_SESSION_TOKEN',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ id: 37421, onlyCurrent: true }),
})
```

### curl — v2 mode

```bash
curl -X POST "https://vibecode.bitrix24.com/v1/notifications/read?format=v2" \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "ids": [38963] }'
```

## Response fields

Regular mode — without `format=v2`:

| Field | Type | Description |
|------|-----|----------|
| `success` | boolean | `true` on success |
| `data` | boolean | Always `true`. The success indicator is the HTTP code `200`, not the value |

v2 mode — `format=v2`:

| Field | Type | Description |
|------|-----|----------|
| `success` | boolean | `true` on success |
| `data` | object | Result of the call: the unread counter and the notifications marked as read |
| `data.counter` | number | Unread notification counter after the call |
| `data.viewedMessages` | number[] | Identifiers of the notifications marked as read |

## Response example

HTTP 200:

```json
{
  "success": true,
  "data": true
}
```

### Response example — v2 mode

```json
{
  "success": true,
  "data": {
    "counter": 0,
    "viewedMessages": [38963]
  }
}
```

## Error response example

403 — no `im` scope:

```json
{
  "success": false,
  "error": {
    "code": "SCOPE_DENIED",
    "message": "This endpoint requires 'im' scope"
  }
}
```

## Errors

| HTTP | Code | Description |
|------|-----|----------|
| 400 | `INVALID_PARAMS` | v2 mode only: `ids` is not an array of 1–100 positive integer identifiers, another body field or a query string parameter other than `format` was passed, or the body is not a JSON object. The field is named in the message. Checked before the Bitrix24 call |
| 404 | `ENTITY_NOT_FOUND` | v2 mode only: the notifications in `ids` were not found and the portal message says `Message is not found`; `error.b24Code` is `MESSAGE_NOT_FOUND` |
| 422 | `BITRIX_ERROR` | v2 mode only: the notifications in `ids` were not found, but the portal sent only the bare `MESSAGE_NOT_FOUND` code as its message; the code is in `error.b24Code` |
| 422 | `BITRIX_ERROR` | v2 mode only: Bitrix24 rejected the call for another reason; the portal code is in the `error.b24Code` field |
| 403 | `SCOPE_DENIED` | The key lacks the `im` scope |
| 403 | `WRITE_BLOCKED_READONLY_KEY` | The key is in read-only mode |
| 401 | `TOKEN_MISSING` | The key has no configured tokens |

Full list of common API errors — [Errors](/docs/errors).

## Known specifics

- The body is optional. A request without a body and a request with an empty body are handled as the body `{}`, with or without the `Content-Type: application/json` header.
- A request without an `id` field succeeds and leaves notification statuses unchanged. Pass `id` to actually mark notifications.

## See also

- [Send a notification](./send.md)
- [Mark all as read](./read-all.md)
- [Delete by id](./delete.md)
- [Errors](/docs/errors)