For AI agents: markdown of this page — /docs-content-en/entities/calendar-sections/fields.md documentation index — /llms.txt

Calendar section fields

GET /v1/calendar-sections/fields

Returns the field reference for a calendar section: the value type, the read-only flag, whether the field is required on create, and the list of allowed values for fields with a fixed set.

Examples

curl — personal key

Terminal 
curl "https://vibecode.bitrix24.com/v1/calendar-sections/fields" \
  -H "X-Api-Key: YOUR_API_KEY"

curl — OAuth application

Terminal 
curl "https://vibecode.bitrix24.com/v1/calendar-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/calendar-sections/fields', {
  headers: {
    'X-Api-Key': 'YOUR_API_KEY',
  },
})

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

JavaScript — OAuth application

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

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

Response fields

Field Type Description
Fieldsuccess Typeboolean DescriptionAlways true on success
Fielddata.fields Typeobject DescriptionThe section field reference. The key is the field name in camelCase, the value is its description
Fielddata.fields.<name>.type Typestring DescriptionThe field value type: number, string, boolean, object, or datetime
Fielddata.fields.<name>.readonly Typeboolean Descriptiontrue — the field is filled in by the system; on create and update it is rejected with 400 READONLY_FIELD
Fielddata.fields.<name>.required Typeboolean DescriptionPresent on fields that are required on create
Fielddata.batch Typearray DescriptionSection operations available in a batch request: create, update, delete

A field with a fixed set of values also carries an enum array — every element holds a value to pass in the request and a label caption.

The reference describes fourteen fields:

Field Type RO Description
Fieldid Typenumber ROyes DescriptionSection identifier
Fieldname Typestring RO DescriptionSection name. Required on create
Fielddescription Typestring RO DescriptionSection description
Fieldtype Typestring RO DescriptionCalendar type. Required on create. The allowed values are listed in enum: user — a user calendar, group — a workgroup calendar, company_calendar — a company calendar, location — a meeting-room calendar
FieldownerId Typenumber RO DescriptionCalendar owner identifier. Required on create. For the user type — the employee identifier from GET /v1/users. The owner of the remaining types is described in Calendar sections
Fieldcolor Typestring RO DescriptionSection color in #RRGGBB format
FieldtextColor Typestring RO DescriptionText color in #RRGGBB format
Fieldexport Typeobject RO DescriptionExport parameters in iCal format. The keys inside the object are uppercase
Fieldaccess Typeobject ROyes DescriptionSection access-rights map
Fieldperm Typeobject ROyes DescriptionPermission map of the current employee
FieldisCollab Typeboolean ROyes DescriptionWhether the section belongs to a collab
FieldcreatedBy Typenumber ROyes DescriptionThe employee who created the section. List: GET /v1/users
FielddateCreate Typedatetime ROyes DescriptionSection creation date
FieldupdatedAt Typedatetime ROyes DescriptionDate the section was last modified

Response example

JSON 
{
  "success": true,
  "data": {
    "fields": {
      "id": { "type": "number", "readonly": true },
      "name": { "type": "string", "readonly": false, "required": true },
      "description": { "type": "string", "readonly": false },
      "type": {
        "type": "string",
        "readonly": false,
        "required": true,
        "enum": [
          { "value": "user", "label": "User calendar" },
          { "value": "group", "label": "Workgroup calendar" },
          { "value": "company_calendar", "label": "Company calendar" },
          { "value": "location", "label": "Location calendar" }
        ]
      },
      "ownerId": { "type": "number", "readonly": false, "required": true },
      "color": { "type": "string", "readonly": false },
      "textColor": { "type": "string", "readonly": false },
      "export": { "type": "object", "readonly": false },
      "access": { "type": "object", "readonly": true },
      "perm": { "type": "object", "readonly": true },
      "isCollab": { "type": "boolean", "readonly": true },
      "createdBy": { "type": "number", "readonly": true },
      "dateCreate": { "type": "datetime", "readonly": true },
      "updatedAt": { "type": "datetime", "readonly": true }
    },
    "batch": ["create", "update", "delete"]
  }
}

Error response example

403 — the scope is missing:

JSON 
{
  "success": false,
  "error": {
    "code": "SCOPE_DENIED",
    "message": "This endpoint requires 'calendar' scope"
  }
}

Errors

HTTP Code Description
HTTP403 CodeSCOPE_DENIED DescriptionThe key is missing the calendar scope
HTTP401 CodeMISSING_API_KEY DescriptionThe X-Api-Key header was not passed
HTTP401 CodeTOKEN_MISSING DescriptionThe API key has no Bitrix24 tokens configured
HTTP429 CodeRATE_LIMITED DescriptionRate limit exceeded: 300 requests per minute per portal, all API keys of the portal share one limit. The exact value arrives in the x-ratelimit-limit header (the cap is divided across replicas). Retry after the delay in the Retry-After header

The full list of common API errors — Errors.

Known specifics

The reference is identical on every Bitrix24 account. The response is assembled from the entity description on the Vibecode platform side and is never requested from the account. So the field set, the field types, and the enum values depend neither on the settings of a particular account nor on Bitrix24 availability, and custom fields do not appear in the reference.

See also