## Search tasks

`POST /v1/tasks/search`

Search tasks with filters and sorting. Equivalent to `GET /v1/tasks`, but parameters are passed in the request body — suitable for long and complex filters. The endpoint also automatically splits the result set into weekly windows when filtering by a date range wider than 14 days — this bypasses the ceiling of 5000 records per Bitrix24 call.

Besides the `tasks` scope, the method requires a Bitrix24 plan that includes Vibecode. On a Bitrix24 account without such a plan, the call returns `422 BITRIX_ERROR` with `error.b24Code` set to `FEATURE_NOT_AVAILABLE_ON_CURRENT_PLAN`, and retrying the request does not help. You can check the account's plan before the call: it is returned in the `data.tariff` field of [`GET /v1/me`](/docs/keys-auth/me).

## Request fields (body)

| Parameter | Type | Default | Description |
|----------|-----|-----------|---------|
| `filter` | object | — | Filtering by the fields from `GET /v1/tasks/fields`.<br>[Filtering syntax](/docs/filtering). Example: `{"status": 2, "responsibleId": 1}` |
| `select` | string[] | — | Field selection: `["id", "title", "status", "responsibleId"]` |
| `order` | object | `id desc` | Sorting: `{ "createdDate": "desc" }` |
| `limit` | number | `50` | Number of records (up to 5000) |
| `offset` | number | `0` | Skip N records. Combined with a date-range filter wider than 14 days, the request is rejected — see `UNSTABLE_OFFSET_PAGINATION` in the "Errors" section |
| `autoWindow` | boolean | `true` | Split the result set into weekly windows when filtering by a date range wider than 14 days. `false` disables splitting |
| `withTotal` | boolean | — | Whether you need the count. `false` — remove the count from the response; this is the only guaranteed way to remove `meta.total`, and it has no effect when the result set is split into windows. When `limit` exceeds 50, the platform still needs the count to plan data retrieval, so the parameter removes the count from the response without reducing the workload. If the field is omitted, the API key setting applies, followed by the platform default. [Paging and counts](/docs/entity-api#paging-and-record-counts) |

> **`status` vs `realStatus`.** `filter.status` in Bitrix24 is a virtual (meta) filter (`−1` overdue, `−2` unviewed, `−3` almost overdue), not the number from the `status` field of the response: `{"filter": {"status": 2}}` will not return every task with status `2` — this virtual filter assigns exactly one value to each task, and tasks marked `−1`, `−2` or `−3` do not match the condition. To filter or sort by the actual status, use `realStatus`: `{"filter": {"realStatus": 2}}`, `{"sort": {"realStatus": "asc"}}`.

> **`meta.total` is not returned on every call.** When `limit` is at most 50 and `offset` is zero, you do not have to request the count: if the response contains fewer records than `limit`, `meta.total` is still returned with the exact count (an empty result gives `0`); on a full page the field is absent. When `limit` is above 50, `meta.total` arrives — the count runs only where it cannot be avoided — and an explicit `withTotal=false` removes it there too. When the result set is split into windows (`autoWindowed: true`), the count is requested as before and `withTotal` is ignored. Check whether the field is present in a given response, and page by `meta.hasMore`.

## Examples

### curl — personal key

```bash
curl -X POST "https://vibecode.bitrix24.com/v1/tasks/search" \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "filter": { "status": 2, "responsibleId": 1 },
    "select": ["id", "title", "status", "deadline"],
    "order": { "id": "desc" },
    "limit": 50
  }'
```

### curl — OAuth application

```bash
curl -X POST "https://vibecode.bitrix24.com/v1/tasks/search" \
  -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "filter": { "status": 2, "responsibleId": 1 },
    "select": ["id", "title", "status", "deadline"],
    "order": { "id": "desc" },
    "limit": 50
  }'
```

### JavaScript — personal key

```javascript
const res = await fetch('https://vibecode.bitrix24.com/v1/tasks/search', {
  method: 'POST',
  headers: {
    'X-Api-Key': 'YOUR_API_KEY',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    filter: { status: 2, responsibleId: 1 },
    select: ['id', 'title', 'status', 'deadline'],
    order: { id: 'desc' },
    limit: 50,
  }),
})

const { success, data, meta } = await res.json()
console.log(`Found ${data.length} of ${meta.total} tasks`)
```

### JavaScript — OAuth application

```javascript
const res = await fetch('https://vibecode.bitrix24.com/v1/tasks/search', {
  method: 'POST',
  headers: {
    'X-Api-Key': 'YOUR_APP_KEY',
    'Authorization': 'Bearer USER_SESSION_TOKEN',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    filter: { status: 2, responsibleId: 1 },
    select: ['id', 'title', 'status', 'deadline'],
    order: { id: 'desc' },
    limit: 50,
  }),
})

const { success, data, meta } = await res.json()
```

## Response fields

| Field | Type | Description |
|------|-----|---------|
| `success` | boolean | Always `true` on success |
| `data` | array | Array of tasks (all fields — see [Task fields](./fields.md)) |
| `meta.total` | number | Total number of records matching the filter. An optional field — see the note above |
| `meta.hasMore` | boolean | Whether there are more records beyond `limit` |
| `meta.durationMs` | number | Request duration in milliseconds |
| `meta.autoWindowed` | boolean | `true` if the result set was split into time windows |
| `meta.windowCount` | number | Number of windows. Present with `autoWindowed: true` |
| `meta.batchWaves` | number | Number of parallel request waves. Present with `autoWindowed: true` |

The card URL of any task from the `data` array is built from its `id` and the employee ID:

```
https://<portal>.bitrix24.com/company/personal/user/<responsibleId>/tasks/task/view/<id>/
```

`<responsibleId>` — the responsible person's ID (the `responsibleId` field of each element): the task opens in their personal workspace. The `user/<...>` segment determines whose workspace the tasks page is shown in — substitute the ID of the employee you need, for example the current one. `<portal>` — the Bitrix24 account domain. Access is limited by the employee's permissions in Bitrix24.

## Response example

```json
{
  "success": true,
  "data": [
    {
      "id": 289,
      "title": "Prepare the quarterly report",
      "status": 2,
      "deadline": "2026-05-19T18:00:00.000Z"
    },
    {
      "id": 311,
      "title": "Reconcile with accounting",
      "status": 2,
      "deadline": "2026-05-15T17:00:00.000Z"
    }
  ],
  "meta": {
    "total": 182,
    "hasMore": true,
    "durationMs": 1226
  }
}
```

With a date-range filter wider than 14 days, `meta` additionally returns `autoWindowed`, `windowCount`, and `batchWaves`:

```json
{
  "success": true,
  "data": [ /* ... */ ],
  "meta": {
    "total": 179,
    "hasMore": true,
    "autoWindowed": true,
    "windowCount": 131,
    "batchWaves": 3,
    "durationMs": 1543
  }
}
```

## Error response example

403 — no scope:

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

## Errors

| HTTP | Code | Description |
|------|-----|---------|
| 400 | `UNSTABLE_OFFSET_PAGINATION` | `offset` greater than zero together with a date-range filter wider than 14 days. Two different retrieval algorithms produce inconsistent results, so the request is rejected. Fetch everything in a single request with `limit` up to 5000, or pass `autoWindow: false` with sorting by `id`, or split the date range into parts yourself |
| 403 | `SCOPE_DENIED` | The API key does not have the `tasks` scope |
| 401 | `TOKEN_MISSING` | The API key has no configured tokens |
| 422 | `BITRIX_ERROR` | `error.b24Code` is `FEATURE_NOT_AVAILABLE_ON_CURRENT_PLAN`: the Bitrix24 account's plan does not include Vibecode. Retrying does not help. The account's plan is in the `data.tariff` field of `GET /v1/me` |
| — | `WINDOWED_SEARCH_FAILED` | No longer returned: when auto-windowing fails completely, the real Bitrix24 code is returned — `UNKNOWN_FILTER_FIELD` / `INVALID_PARAMS` / `BITRIX_ACCESS_DENIED` / `RATE_LIMITED` / `BITRIX_UNAVAILABLE` / `BITRIX_TIMEOUT` (503) |
| 429 | `RATE_LIMITED` | Rate limit exceeded: 300 requests per minute per portal. All API keys of the portal share one limit. The current limit is returned in the `x-ratelimit-limit` header. Retry after the delay in the `Retry-After` header |

For the full list of common API errors, see [Errors](/docs/errors).

## Known specifics

**When to choose search over list.** `GET /v1/tasks` is suitable for short filters in the URL. `POST /v1/tasks/search` is used when there are many conditions — nested objects, arrays, date ranges: parameters in the body are easier to read and assemble than a long query string.

**Time-window splitting.** A date-range filter wider than 14 days is automatically split into weekly windows executed in parallel waves, so the result set bypasses the ceiling of 5000 records per call. `meta` then returns `autoWindowed: true`, the number of windows `windowCount`, and the number of waves `batchWaves`. The `autoWindow: false` parameter disables splitting. While splitting is active, an `offset` greater than zero is rejected with `UNSTABLE_OFFSET_PAGINATION`.

**Value types match the schema.** Fields declared as numbers in the [schema](./fields.md) — `id`, `status`, `priority`, `responsibleId`, `createdBy`, `groupId` and similar — come as numbers. Yes/no flags come as `true` and `false`. Converting via `Number(value)` is not required.

## See also

- [List tasks](./list.md)
- [Task fields](./fields.md)
- [Aggregate tasks](./aggregate.md)
- [Filtering syntax](/docs/filtering)
- [Batch](/docs/batch)
- [Limits and optimization](/docs/optimization)