For AI agents: markdown of this page — /docs-content-en/entities/bank-details/search.md documentation index — /llms.txt
Search bank details
POST /v1/bank-details/search
Search for bank details with filters and auto-pagination. Equivalent to GET /v1/bank-details, but parameters are passed in the request body — suitable for complex filters with many conditions and for building requests programmatically.
Request fields (body)
| Parameter | Type | Default | Description |
|---|---|---|---|
filter |
object | — | Filtering by GET /v1/bank-details/fields fields.Filtering syntax. Example: { "entityId": 3, "active": true } |
limit |
number | 50 |
Number of records (up to 5000) |
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 |
order |
object | — | Sorting: { "id": "desc" } |
select |
string[] | — | Field selection: ["id", "name", "rqBik", "rqAccNum"] |
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
curl -X POST "https://vibecode.bitrix24.com/v1/bank-details/search" \
-H "X-Api-Key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"filter": { "entityId": 3, "active": true },
"limit": 20,
"order": { "id": "asc" }
}'
curl — OAuth app
curl -X POST "https://vibecode.bitrix24.com/v1/bank-details/search" \
-H "X-Api-Key: YOUR_APP_KEY" \
-H "Authorization: Bearer USER_SESSION_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"filter": { "entityId": 3, "active": true },
"limit": 20,
"order": { "id": "asc" }
}'
JavaScript — personal key
const res = await fetch('https://vibecode.bitrix24.com/v1/bank-details/search', {
method: 'POST',
headers: {
'X-Api-Key': 'YOUR_API_KEY',
'Content-Type': 'application/json',
},
body: JSON.stringify({
filter: { entityId: 3, active: true },
limit: 20,
order: { id: 'asc' },
}),
})
const { success, data } = await res.json()
console.log('Found:', data.length)
JavaScript — OAuth app
const res = await fetch('https://vibecode.bitrix24.com/v1/bank-details/search', {
method: 'POST',
headers: {
'X-Api-Key': 'YOUR_APP_KEY',
'Authorization': 'Bearer USER_SESSION_TOKEN',
'Content-Type': 'application/json',
},
body: JSON.stringify({
filter: { entityId: 3, active: true },
limit: 20,
order: { id: 'asc' },
}),
})
const { success, data } = await res.json()
Other scenarios
All bank details of a single requisite:
{ "filter": { "entityId": 11 } }
Filter by BIC:
{ "filter": { "rqBik": "13142323452" } }
With a selection of specific fields:
{
"filter": { "active": true },
"select": ["id", "entityId", "name", "rqBik", "rqAccNum"],
"order": { "id": "asc" }
}
Response fields
| Field | Type | Description |
|---|---|---|
success |
boolean | Always true on success |
data |
array | Array of bank details (all fields — see Bank detail fields) |
meta.total |
number | Total number of records matching the filter |
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 meta fields sit next to data, not inside it. Pages must be walked by meta.hasMore: a data length equal to limit does not rule out the last page.
Response example
{
"success": true,
"data": [
{
"id": 3,
"entityId": 3,
"countryId": 1,
"name": "Bank details 1",
"active": true,
"sort": 500,
"code": null,
"xmlId": null,
"rqBankName": "Details 1",
"rqBankAddr": null,
"rqBik": null,
"rqAccNum": null,
"rqCorAccNum": null,
"rqSwift": null,
"rqIban": null,
"createdAt": "2020-05-22T11:56:53.000Z",
"updatedAt": "2023-12-05T11:50:19.000Z",
"createdBy": 1,
"modifyBy": 779
},
{
"id": 5,
"entityId": 11,
"countryId": 1,
"name": "Bank details 1",
"active": true,
"sort": 500,
"code": null,
"xmlId": null,
"rqBankName": "bank",
"rqBankAddr": "test address",
"rqBik": "13142323452",
"rqAccNum": "234245746878032451534",
"rqCorAccNum": "235134524566748725431",
"rqSwift": null,
"rqIban": null,
"createdAt": "2020-06-30T09:53:58.000Z",
"updatedAt": null,
"createdBy": 1,
"modifyBy": null
}
],
"meta": {
"total": 6,
"hasMore": true
}
}
With a date-range filter wider than 14 days, meta additionally returns autoWindowed, windowCount, and batchWaves:
{
"success": true,
"data": [ /* ... */ ],
"meta": {
"total": 2,
"hasMore": false,
"autoWindowed": true,
"windowCount": 131,
"batchWaves": 3,
"durationMs": 1497
}
}
Error response example
403 — no scope:
{
"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 |
| 403 | SCOPE_DENIED |
API key lacks the crm scope |
| 401 | TOKEN_MISSING |
API key has no configured tokens |
| 400 | INVALID_FILTER |
Error in filter syntax |
Full list of common API errors — 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.
entityTypeId is not returned in the response. This field is passed only on creation. It is absent from search responses — filter by entityId (ID of the owner requisite).
Pagination. When limit > 50, the request is automatically split into several calls to Bitrix24. For large result sets, use offset and paginated requests.