
## Section fields

`GET /v1/product-sections/fields`

Returns a reference listing product section fields, their types, and whether they are read-only, plus the list of operations available in a [batch request](/docs/batch).

## Examples

### curl — personal key

```bash
curl "https://vibecode.bitrix24.com/v1/product-sections/fields" \
  -H "X-Api-Key: YOUR_API_KEY"
```

### curl — OAuth application

```bash
curl "https://vibecode.bitrix24.com/v1/product-sections/fields" \
  -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN"
```

### JavaScript — personal key

```javascript
const res = await fetch('https://vibecode.bitrix24.com/v1/product-sections/fields', {
  headers: { 'X-Api-Key': 'YOUR_API_KEY' },
})

const { success, data } = await res.json()
console.log('Total fields:', Object.keys(data.fields).length)
```

### JavaScript — OAuth application

```javascript
const res = await fetch('https://vibecode.bitrix24.com/v1/product-sections/fields', {
  headers: {
    'X-Api-Key': 'YOUR_APP_KEY',
    'Authorization': 'Bearer USER_SESSION_TOKEN',
  },
})

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

## Response fields

`data.fields` is an object whose key matches the field name and whose value contains `type` (the field type), `readonly` (`true` — the field cannot be passed on create or update), `label` (a human-readable field name in English) and — on a field whose value Bitrix24 never returns — `notReturned: true` together with a `description`. Request headers do not switch the language. `data.batch` is the list of operations accepted by a [batch request](/docs/batch).

| Field | Bitrix24 | Type | RO | Description |
|------|----------|-----|:--:|---------|
| `id` | `ID` | number | yes | Section identifier |
| `name` | `NAME` | string | | Section name |
| `catalogId` | `CATALOG_ID` | number | | Catalog identifier. List: `GET /v1/catalogs` |
| `sectionId` | `SECTION_ID` | number | | Parent section identifier for nesting. `null` for a root section |
| `xmlId` | `XML_ID` | string | | External identifier for synchronization |
| `sort` | `SORT` | number | yes | Sort order, lower comes first. The value is not saved on write and is not returned on read (`notReturned: true`) — it only works for ordering |
| `code` | `CODE` | string | | Section symbolic code |

| Field | Type | Description |
|------|-----|---------|
| `success` | boolean | Always `true` on success |
| `data.fields.<name>.type` | string | Field type: `number`, `string` |
| `data.fields.<name>.readonly` | boolean | `true` — the field is filled in by the system and not accepted on create or update |
| `data.fields.<name>.label` | string | Human-readable field name in English |
| `data.fields.<name>.description` | string | Longer field description, when there is one |
| `data.fields.<name>.notReturned` | boolean | `true` — Bitrix24 never returns this field's value in any response. The key is present only on such fields |
| `data.batch` | string[] | Section operations available in a [batch request](/docs/batch): `create`, `update`, `delete` |

The `sort` field is **not accepted on write and not returned on read**. Verified on a live Bitrix24 account: a value passed on create or update is not saved (and Bitrix24 still reports success for the update), and no response — `list`, `get`, `search`, or the create response — carries it. An explicit `select=sort` is refused with `400 SELECT_FIELD_NOT_RETURNED`. So sending `sort` in `POST` or `PATCH` is now refused with `400 READONLY_FIELD` instead of a silent success, and the field reference marks it `notReturned: true`. **Ordering by it does work** — `?sort=sort&order=asc` and `order=desc` return sections in different orders. Filtering by it is not supported. To change the order of sections, edit them in the Bitrix24 interface. The `id`, `name`, `sectionId`, `xmlId`, and `code` fields support exact-match filtering (and `$in`); operators return `400 UNSUPPORTED_FILTER`. The `sectionId`, `xmlId`, and `code` fields come back with a `null` value if not set. If `code` is not provided on create, it is generated from `name`.

The filter accepts `catalogId`, but it does not narrow the results: list and search return only sections of the CRM product catalog.

## Available includes

The `GET /v1/product-sections/fields` endpoint returns the list of available includes: `catalog`, `parentSection`.

Usage example: [Get a product section](/docs/entities/product-sections/get#related-data).

More on includes: [Related data](/docs/includes).

## Response example

```json
{
  "success": true,
  "data": {
    "fields": {
      "id": { "type": "number", "readonly": true },
      "name": { "type": "string", "readonly": false },
      "catalogId": { "type": "number", "readonly": false },
      "sectionId": { "type": "number", "readonly": false },
      "xmlId": { "type": "string", "readonly": false },
      "sort": {
        "type": "number",
        "readonly": true,
        "notReturned": true,
        "label": "Sort order",
        "description": "Sort order of the section among its siblings. Bitrix24 neither saves a value passed on create or update nor returns one on read, so the field is refused on write with 400 READONLY_FIELD and its value is never returned. The field is listed here so callers can find it and read the explanation. Ordering by it DOES work: pass ?sort=sort&order=asc|desc and Bitrix24 sorts by the stored column. To change the order, edit the section in the Bitrix24 interface."
      },
      "code": { "type": "string", "readonly": false }
    },
    "batch": ["create", "update", "delete"]
  }
}
```

## Error response example

403 — no scope:

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

## Errors

| HTTP | Code | Description |
|------|-----|---------|
| 403 | `SCOPE_DENIED` | The API key does not have the `crm` scope |
| 401 | `MISSING_API_KEY` | The `X-Api-Key` header was not provided |
| 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).

## See also

- [Create section](/docs/entities/product-sections/create)
- [List sections](/docs/entities/product-sections/list)
- [Product sections](/docs/entities/product-sections)
- [Entity API](/docs/entity-api)
