Aggregate order statuses

POST /v1/order-statuses/aggregate

Counts statuses grouped by type or notify. The only numeric field is sort, so numeric functions (sum, avg) are rarely useful — the main scenario is count with a filter or grouping.

Standard fields

All status fields are categorical — suitable only for groupBy and filter:

The full list of aggregatable fields is shown in the table above.

Request fields (body)

Examples

curl — personal key

curl -X POST "https://vibecode.bitrix24.com/v1/order-statuses/aggregate" \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "groupBy": "type"
  }'

curl — OAuth application

curl -X POST "https://vibecode.bitrix24.com/v1/order-statuses/aggregate" \
  -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "groupBy": "type"
  }'

JavaScript — personal key

const res = await fetch('https://vibecode.bitrix24.com/v1/order-statuses/aggregate', {
  method: 'POST',
  headers: {
    'X-Api-Key': 'YOUR_API_KEY',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    groupBy: 'type',
  }),
})

const { success, data } = await res.json()
console.log('Status distribution:', data.groups)

JavaScript — OAuth application

const res = await fetch('https://vibecode.bitrix24.com/v1/order-statuses/aggregate', {
  method: 'POST',
  headers: {
    'X-Api-Key': 'YOUR_APP_KEY',
    'Authorization': 'Bearer USER_SESSION_TOKEN',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    groupBy: 'type',
  }),
})

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

Other scenarios

Count records — count with field "*", the fastest request without fetching records. Without the aggregate array the result is the same:

{ "aggregate": [{ "field": "*", "function": "count" }] }

How many statuses have notifications enabled:

{
  "filter": { "notify": true }
}

Group by both axes at once:

{
  "groupBy": ["type", "notify"]
}

Response fields

Response example

{
  "success": true,
  "data": {
    "count": 9,
    "aggregates": {},
    "groups": [
      { "type": "O", "count": 6, "aggregates": {} },
      { "type": "D", "count": 3, "aggregates": {} }
    ],
    "meta": {
      "totalRecords": 9,
      "recordsProcessed": 9,
      "truncated": false,
      "groupTotal": 2,
      "groupsTruncated": false
    }
  }
}

Without groupBy, the data.groups field is absent from the response.

Error response example

400 — unknown field in groupBy:

{
  "success": false,
  "error": {
    "code": "INVALID_PARAMS",
    "message": "groupBy field 'foo' is not aggregatable on this entity. Available: type, notify."
  }
}

Errors

For the full list of general API errors, see Errors.

Known specifics

In practice only count is needed. The only numeric field of a status is sort, and it is the only one the sum / avg / min / max functions accept; for any other field, they return 400 INVALID_PARAMS. To count statuses, use count (without aggregate) with a filter or grouping.

Small data volume. A Bitrix24 account holds only dozens of statuses, so the 5000-record ceiling is never reached for this entity.

The truncation marker travels with the number itself. When a response arrives with meta.truncated: true, the marker truncated: true sits inside every field object in data.aggregates and on every element of data.groups, and data.meta.warnings gains a warning with the code AGGREGATE_TRUNCATED. A client that reads only the number itself therefore sees that it was computed over only some of the records. None of these markers appear on a complete response. For full details, see Aggregation POST — the 5000-record ceiling.

See also

• List statuses
• Search statuses
• Status fields
• Filtering syntax
• Limits and optimization