#Smart process type fields
GET /v1/smart-processes/fields
Returns the field schema of a smart process type: which fields can be passed on create and update, and which are read-only.
#Examples
#curl — personal key
curl "https://vibecode.bitrix24.tech/v1/smart-processes/fields" \
-H "X-Api-Key: YOUR_API_KEY"
#curl — OAuth app
curl "https://vibecode.bitrix24.tech/v1/smart-processes/fields" \
-H "X-Api-Key: YOUR_APP_KEY" \
-H "Authorization: Bearer USER_SESSION_TOKEN"
#JavaScript — personal key
const res = await fetch('https://vibecode.bitrix24.tech/v1/smart-processes/fields', {
headers: {
'X-Api-Key': 'YOUR_API_KEY',
},
})
const { success, data } = await res.json()
console.log('Fields:', Object.keys(data.fields).length)
#JavaScript — OAuth app
const res = await fetch('https://vibecode.bitrix24.tech/v1/smart-processes/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 | Internal ID of the type record |
entityTypeId |
number | Entity type ID. Passed to /v1/items/:entityTypeId to work with items. If not provided on create, Bitrix24 assigns a free value automatically |
|
title |
string | Smart process type name | |
code |
string | null | Symbolic code of the type (for programmatic identification). null if not set |
|
customSectionId |
number | null | ID of the custom workspace the type is bound to. null if not bound. Written on create but not updated |
|
isCategoriesEnabled |
boolean | Use custom sales funnels and tunnels in the smart process | |
isStagesEnabled |
boolean | Use custom stages and kanban in the smart process | |
isBeginCloseDatesEnabled |
boolean | "Start date" and "End date" fields | |
isClientEnabled |
boolean | "Client" field linked to contacts and companies | |
isLinkWithProductsEnabled |
boolean | Catalog product linking | |
isMycompanyEnabled |
boolean | "Your company details" field | |
isObserversEnabled |
boolean | "Observers" field | |
isSourceEnabled |
boolean | "Source" and "Source details" fields | |
isAutomationEnabled |
boolean | Automation rules and triggers | |
isBizProcEnabled |
boolean | Business process designer | |
isDocumentsEnabled |
boolean | Document printing | |
isRecyclebinEnabled |
boolean | Recycle bin usage | |
isSetOpenPermissions |
boolean | Make new funnels available to everyone | |
isUseInUserfieldEnabled |
boolean | Use the smart process in a custom field | |
isRecurringEnabled |
boolean | "Recurrence" field | |
isPaymentsEnabled |
boolean | Online payment | |
isCountersEnabled |
boolean | Counters (notifications and badges) | |
isInitialized |
boolean | yes | Type is fully initialized in the portal |
createdBy |
number | yes | Who created it. Lookup: GET /v1/users |
updatedBy |
number | yes | Who changed it. Lookup: GET /v1/users |
createdTime |
datetime | yes | Creation date |
updatedTime |
datetime | yes | Update date |
The response also contains a batch array listing the operations available for batch processing: create, update, delete.
datetime format.
createdTime/updatedTimearrive in ISO 8601, but the exact representation (with a+03:00offset or UTC…Zwith milliseconds) depends on the portal — parse as ISO 8601, do not compare strings byte by byte.
#Response example
{
"success": true,
"data": {
"fields": {
"id": { "type": "number", "readonly": true },
"entityTypeId": { "type": "number", "readonly": false },
"title": { "type": "string", "readonly": false },
"isCategoriesEnabled": { "type": "boolean", "readonly": false },
"isStagesEnabled": { "type": "boolean", "readonly": false },
"isLinkWithProductsEnabled": { "type": "boolean", "readonly": false },
"code": { "type": "string", "readonly": false, "label": "Symbolic code" },
"createdBy": { "type": "number", "readonly": true, "label": "Created by" },
"customSectionId": { "type": "number", "readonly": false, "label": "Custom workspace" },
"createdTime": { "type": "datetime", "readonly": true, "label": "Creation date" }
},
"batch": ["create", "update", "delete"]
}
}
Showing 10 of 27 fields. Full list — in the table above.
#Error response example
401 — key not provided:
{
"success": false,
"error": {
"code": "MISSING_API_KEY",
"message": "API key required. Pass via X-Api-Key header."
}
}
#Errors
| HTTP | Code | Description |
|---|---|---|
| 401 | MISSING_API_KEY |
X-Api-Key header not provided |
| 401 | INVALID_API_KEY |
Key not found or revoked |
| 403 | SCOPE_DENIED |
API key lacks the crm scope |
| 401 | TOKEN_MISSING |
API key has no configured tokens |
Full list of common API errors — Errors.
#Known specifics
Nested structures. On create and update you can pass the relations (links to other CRM types) and linkedUserFields (linked custom fields) fields. They are not described in the /fields response, but Bitrix24 accepts and stores them unchanged. More details — in Create type.
label — localized name from Bitrix24. For some fields a label field is returned with the caption that Bitrix24 shows in the interface (for example, createdBy.label = "Created by"). Convenient for building your own forms and lists.
Difference from GET /v1/{entity}/fields of standard entities. This endpoint describes the fields of the smart process type (crm.type.*), not of the items inside it. For item fields use GET /v1/items/:entityTypeId/fields.
#See also
- Type list — all types on the portal
- Create type — which fields to pass
- Update type — partial update
- Smart process items — CRUD over items
- Item fields —
GET /v1/items/:entityTypeId/fields - Custom fields — managing
ufCrm_* - Limits and optimization — rate limits