## Search leads

`POST /v1/leads/search`

Search leads by conditions in the request body. Accepts the same filters as the lead list and is designed for compound conditions and large result sets.

## Request fields (body)

| Parameter | Type | Default | Description |
|----------|-----|-----------|---------|
| `filter` | object | — | Filter by fields returned by `GET /v1/leads/fields`.<br>[Filtering syntax](/docs/filtering). Example: `{ "stageId": "NEW" }` |
| `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 |
| `order` | object | — | Sorting: `{ "createdTime": "desc" }` |
| `select` | string[] | — | Field selection: `["id", "title", "stageId", "amount"]` |
| `autoWindow` | boolean | `true` | Split the result set into weekly windows when filtering by a date range wider than 14 days. `false` disables splitting |

## Examples

### curl — personal key

```bash
curl -X POST "https://vibecode.bitrix24.com/v1/leads/search" \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "filter": { "stageId": "NEW", ">=amount": 1000 },
    "limit": 10,
    "order": { "createdTime": "desc" }
  }'
```

### curl — OAuth application

```bash
curl -X POST "https://vibecode.bitrix24.com/v1/leads/search" \
  -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "filter": { "stageId": "NEW", ">=amount": 1000 },
    "limit": 10,
    "order": { "createdTime": "desc" }
  }'
```

### JavaScript — personal key

```javascript
const res = await fetch('https://vibecode.bitrix24.com/v1/leads/search', {
  method: 'POST',
  headers: {
    'X-Api-Key': 'YOUR_API_KEY',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    filter: { stageId: 'NEW', '>=amount': 1000 },
    limit: 10,
    order: { createdTime: 'desc' },
  }),
})

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

### JavaScript — OAuth application

```javascript
const res = await fetch('https://vibecode.bitrix24.com/v1/leads/search', {
  method: 'POST',
  headers: {
    'X-Api-Key': 'YOUR_APP_KEY',
    'Authorization': 'Bearer USER_SESSION_TOKEN',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    filter: { stageId: 'NEW', '>=amount': 1000 },
    limit: 10,
    order: { createdTime: 'desc' },
  }),
})

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

## Response fields

| Field | Type | Description |
|------|-----|---------|
| `data` | array | Array of leads (fields — see [Fields](/docs/entities/leads/fields)) |
| `meta.total` | number | How many records matched the filter |
| `meta.hasMore` | boolean | Whether there are more records beyond `limit` |
| `meta.nextAfterId` | string | The identifier of the last returned record. Returned when the sort is strictly `id` ascending, while `hasMore` is `true`. Pass it back in the `>id` filter — a cheap replacement for a growing `offset` |
| `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. Paginate using `meta.hasMore`: a `data` length equal to `limit` does not rule out the last page.

The card URL of any lead from the `data` array is built from its `id`:

```
https://<portal>.bitrix24.com/crm/lead/details/<id>/
```

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

## Response example

```json
{
  "success": true,
  "data": [
    {
      "id": 42,
      "title": "Website request #42",
      "stageId": "NEW",
      "opportunity": 1500,
      "currencyId": "USD",
      "assignedById": 1,
      "sourceId": "WEB",
      "createdTime": "2026-04-10T14:30:00+00:00"
    }
  ],
  "meta": {
    "total": 31,
    "hasMore": true,
    "durationMs": 653
  }
}
```

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

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

## 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. 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 `crm` scope |
| 401 | `TOKEN_MISSING` | The API key has no configured tokens |
| 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

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

**Filtering and sorting by stage semantics.** The `stageSemanticId` field takes three values — `P` for stages in progress, `S` for successful ones, and `F` for failed ones. In `filter` both an exact match `{ "stageSemanticId": "S" }` and a list `{ "stageSemanticId": { "$in": ["S", "F"] } }` work; `order` accepts `{ "stageSemanticId": "asc" }`. A value outside those three is not rejected: no record matches it, and `data` comes back empty. Grouping by this field is not supported in [Aggregate leads](/docs/entities/leads/aggregate).

**The phone filter is not suitable for every search.** A value without an operator is compared against the whole stored string: a lead whose number is stored as `+1 (202) 555-0123` matches that exact string, but not `12025550123`, because the plus sign, spaces, parentheses, and hyphens are part of the value. The filter also checks only the first number stored on a record: if both a work number and a mobile number are stored, searching by the mobile one returns an empty list. To find a lead by phone number in any format and by any of its numbers, use [Duplicate search](/docs/duplicates). The `$contains` operator does work here — it matches a fragment of text inside the value, which makes it a practical approach for email: `{ "email": { "$contains": "@example.com" } }`.

## See also

- [List leads](/docs/entities/leads/list)
- [Duplicate search](/docs/duplicates)
- [Filtering syntax](/docs/filtering)
- [Batch](/docs/batch)
- [Limits and optimization](/docs/optimization)