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

Company fields

GET /v1/companies/fields

Returns the full list of available fields, including user fields (ufCrm_*).

Examples

curl — personal key

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

curl — OAuth application

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

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

JavaScript — OAuth application

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

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

Response fields

Field Type RO Description
id number yes Company ID
title string Name
typeId string Company type: CUSTOMER, SUPPLIER, COMPETITOR. Values list: GET /v1/statuses?filter[entityId]=COMPANY_TYPE
industry string Industry. List: GET /v1/statuses?filter[entityId]=INDUSTRY
revenue number Annual revenue
currencyId string Currency. List: GET /v1/currencies
phone multifield Phone. On input (POST/PATCH) accepts string | string[] | object[]. On output phone is a string with the primary value, per-type values are in phoneWork/phoneMobile, and the full list with types is in the fm[] array (format { id, typeId, valueType, value }). Important: PATCH only adds new records — existing phone entries are not removed. See Update company. Important: the UPPER form [{ "VALUE": "...", "VALUE_TYPE": "WORK" }] is not accepted — it returns 400 INVALID_MULTIFIELD_SHAPE. Use camelCase: [{ "value": "...", "typeId": "WORK" }].
email multifield Email. On input accepts string | string[] | object[]. On output email is a string with the primary value, per-type values are in emailWork/emailHome/emailMailing, and the full list is in the fm[] array. Important: PATCH only adds new records — existing email entries are not removed. Important: the UPPER form [{ "VALUE": "...", "VALUE_TYPE": "WORK" }] is not accepted — it returns 400 INVALID_MULTIFIELD_SHAPE. Use camelCase: [{ "value": "...", "typeId": "WORK" }].
web multifield Website. On input accepts string | string[] | object[]. On output web is a string with the primary value, per-type values are in webWork, and the full list is in the fm[] array. Important: PATCH only adds new records — existing web entries are not removed. Important: the UPPER form [{ "VALUE": "...", "VALUE_TYPE": "WORK" }] is not accepted — it returns 400 INVALID_MULTIFIELD_SHAPE. Use camelCase: [{ "value": "...", "typeId": "WORK" }].
hasPhone boolean yes Whether a phone is set
hasEmail boolean yes Whether an email is set
hasImol boolean yes Whether there is an Open Channel contact
comments string Comment
sourceId string Source. List: GET /v1/statuses?filter[entityId]=SOURCE
sourceDescription string Source description
assignedById number Responsible person. List: GET /v1/users
createdBy number yes Creator. Lookup: GET /v1/users
updatedBy number yes Modified by. Lookup: GET /v1/users
createdTime datetime yes Creation date
updatedTime datetime yes Modification date
opened boolean Available to everyone
leadId number ID of the source lead
entityTypeId number yes CRM entity type ID. For a company the value is always 4
emailWork string | null yes Work e-mail from the email multifield. Written through email
emailHome string | null yes Personal e-mail from the email multifield. Written through email
emailMailing string | null yes Mailing e-mail from the email multifield. Written through email
phoneWork string | null yes Work phone from the phone multifield. Written through phone
phoneMobile string | null yes Mobile phone from the phone multifield. Written through phone
phoneMailing string | null yes Mailing phone from the phone multifield. Written through phone
imol string | null yes Open Channel contact from the multifield collection
address string | null yes Actual address as a single line. Edited in the company requisites
addressLegal string | null yes Legal address as a single line. Edited in the company requisites
searchContent string | null yes Service field. A string Bitrix24 assembles from the card text for its own full-text search. Filtering by it is accepted, but do not rely on it: its composition can change without notice. Do not show it to users either

The eleven fields above arrive in list/get data but cannot be written directly: Bitrix24 returns a success response but does not store the value, so the platform refuses them with 400 READONLY_FIELD. Addresses are edited in the company requisites, and phone numbers and e-mail addresses are written through the phone and email multifields.

User fields (ufCrm_*) are also returned and accepted. The set of such fields differs per Bitrix24 account, so they are not part of the static schema — their descriptions come from Bitrix24.

Response example

JSON 
{
  "success": true,
  "data": {
    "fields": {
      "id": { "type": "number", "readonly": true, "label": "ID", "description": "Company identifier." },
      "title": { "type": "string", "readonly": false, "label": "Name", "description": "Company name." },
      "assignedById": { "type": "number", "readonly": false, "label": "Responsible person", "description": "User responsible for the company." }
    },
    "batch": ["create", "update", "delete"]
  }
}

Only 3 of the many fields are shown. The full list is in the table above. Besides type and readonly, each field carries label (a human-readable name) and description (a short description), returned in English, while labels that the platform takes straight from the Bitrix24 account come in the account language. Request headers do not switch the language.

Errors

HTTP Code Description
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 exact value arrives in the x-ratelimit-limit header (the cap is divided across replicas). Retry after the delay in the Retry-After header

Full list of common API errors — Errors.

See also