
## Search smart process types

`POST /v1/smart-processes/search`

Search smart process types with filters in the POST request body. Used when there are several filter conditions that do not fit into a query string.

## Request fields (body)

| Parameter | Type | Default | Description |
|----------|-----|-----------|---------|
| `filter` | object | `{}` | Filter by any type fields (`title`, `entityTypeId`, `isStagesEnabled`, `isClientEnabled`, `isAutomationEnabled`, etc.). [Filtering syntax](/docs/filtering) |
| `limit` | number | `50` | Number of records in the response |
| `offset` | number | `0` | Skip N records. Together with a date-range filter wider than 14 days it 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 |

Full list of fields you can filter by: [Type fields](/docs/entities/smart-processes/fields).

## Examples

### curl — personal key

```bash
curl -X POST "https://vibecode.bitrix24.com/v1/smart-processes/search" \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "filter": { "isClientEnabled": true, "isStagesEnabled": true },
    "limit": 10
  }'
```

### curl — OAuth application

```bash
curl -X POST "https://vibecode.bitrix24.com/v1/smart-processes/search" \
  -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "filter": { "isClientEnabled": true, "isStagesEnabled": true },
    "limit": 10
  }'
```

### JavaScript — personal key

```javascript
const res = await fetch('https://vibecode.bitrix24.com/v1/smart-processes/search', {
  method: 'POST',
  headers: {
    'X-Api-Key': 'YOUR_API_KEY',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    filter: { isClientEnabled: true, isStagesEnabled: true },
    limit: 10,
  }),
})

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

### JavaScript — OAuth application

```javascript
const res = await fetch('https://vibecode.bitrix24.com/v1/smart-processes/search', {
  method: 'POST',
  headers: {
    'X-Api-Key': 'YOUR_APP_KEY',
    'Authorization': 'Bearer USER_SESSION_TOKEN',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    filter: { isClientEnabled: true, isStagesEnabled: true },
    limit: 10,
  }),
})

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

## Response fields

| Field | Type | Description |
|------|-----|---------|
| `data` | array | Array of types matching the filter. The fields of each type — see [Type fields](/docs/entities/smart-processes/fields) |
| `meta.total` | number | How many records matched the filter |
| `meta.hasMore` | boolean | Whether there is a next page |
| `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 `meta` fields sit next to `data`, not inside it. Pages must be walked using `meta.hasMore`: a `data` length equal to `limit` does not rule out the last page.

The list of items of any type from the `data` array opens in Bitrix24 by `entityTypeId`:

```
https://<portal>.bitrix24.com/crm/type/<entityTypeId>/list/category/0/
```

`0` — the main pipeline. `<portal>` — the Bitrix24 account domain. Access is restricted by the employee's permissions in Bitrix24.

## Response example

```json
{
  "success": true,
  "data": [
    {
      "id": 3,
      "entityTypeId": 174,
      "title": "Contracts",
      "isStagesEnabled": true,
      "isClientEnabled": true,
      "isCategoriesEnabled": true,
      "isLinkWithProductsEnabled": true
    }
  ],
  "meta": { "total": 7, "hasMore": false, "durationMs": 884 }
}
```

Each object shows 7 fields. The full response contains all type fields.

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

```json
{
  "success": true,
  "data": [],
  "meta": {
    "total": 0,
    "hasMore": false,
    "autoWindowed": true,
    "windowCount": 131,
    "batchWaves": 3,
    "durationMs": 1492
  }
}
```

## Error response example

403 — no scope:

```json
{
  "success": false,
  "error": {
    "code": "SCOPE_DENIED",
    "message": "This endpoint requires 'crm' 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. Take 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 |
| 401 | `MISSING_API_KEY` | The `X-Api-Key` header was not passed |
| 401 | `INVALID_API_KEY` | The key was not found or was revoked |
| 403 | `SCOPE_DENIED` | The API key does not have the `crm` scope |
| 401 | `TOKEN_MISSING` | The API key has no configured tokens |
| 422 | `BITRIX_ERROR` | An error from Bitrix24. The specific reason is in the `message` field |

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

## Known specifics

**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`.

**Pass boolean filters as `true`/`false`**, not as `"Y"`/`"N"` — Vibecode converts them for Bitrix24 itself.

**When to use search instead of list.** When you need several filter conditions at once — the request body is more readable than a long query string. To get all types, `GET /v1/smart-processes` is enough.

## See also

- [Type list](/docs/entities/smart-processes/list)
- [Type fields](/docs/entities/smart-processes/fields)
- [Get a type](/docs/entities/smart-processes/get)
- [Smart process items](/docs/entities/items)
- [Filtering syntax](/docs/filtering)
- [Limits and optimization](/docs/optimization)
