## Workspace fields

`GET /v1/automated-solutions/fields`

Returns descriptions of all digital workspace fields, with their type and read-only flag. Fields without this flag are writable on create and update.

## Examples


### curl — personal key

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

### curl — OAuth application

```bash
curl "https://vibecode.bitrix24.com/v1/automated-solutions/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/automated-solutions/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/automated-solutions/fields', {
  headers: {
    'X-Api-Key': 'YOUR_APP_KEY',
    'Authorization': 'Bearer USER_SESSION_TOKEN',
  },
})

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

## Response fields

| Field | Type | Description |
|------|-----|---------|
| `success` | boolean | Always `true` on success |
| `data.fields` | object | Map of workspace fields: the key is the field name, the value describes the field. The fields are listed in the table below |
| `data.fields.<field>.type` | string | Value type: `number`, `string` or `array` |
| `data.fields.<field>.readonly` | boolean | `true` — the field is read-only and is not sent on create or update |
| `data.fields.<field>.required` | boolean | Present and set to `true` on the field required on create: `title` |
| `data.fields.<field>.label` | string | Field label |
| `data.fields.<field>.description` | string | Field description |
| `data.fields.typeIds.itemSchema.type` | string | Item type of the `typeIds` array: `number` |
| `data.batch` | array | Operations available for a workspace in [batch calls](/docs/batch): `create`, `update`, `delete` |

Workspace fields in the `data.fields` map:

| Field | Type | RO | Description |
|------|-----|:--:|---------|
| `id` | number | yes | Workspace identifier. Assigned on create |
| `title` | string | | Workspace name. Required on create |
| `typeIds` | array | | IDs of the bound smart process types — the type `id` field from [`GET /v1/smart-processes`](/docs/entities/smart-processes/list), not its `entityTypeId`. The items are numbers. A value that matches no type of the portal is rejected with `400 UNKNOWN_TYPE_ID` when the portal's type list is available; if it is unavailable or incomplete, the write proceeds unchecked. Not accepted in the list filter or sort |

## Response example

```json
{
  "success": true,
  "data": {
    "fields": {
      "id": {
        "type": "number",
        "readonly": true,
        "label": "Workspace ID",
        "description": "Identifier of the digital workspace. Assigned by Bitrix24 on creation."
      },
      "title": {
        "type": "string",
        "readonly": false,
        "required": true,
        "label": "Title",
        "description": "Name of the digital workspace. The link to the workspace section on the portal is derived from this title, so renaming the workspace also changes its link."
      },
      "typeIds": {
        "type": "array",
        "readonly": false,
        "label": "Linked smart process types",
        "description": "IDs of the smart process types attached to this workspace — the type `id` from GET /v1/smart-processes, NOT its entityTypeId. This is the write path for attaching a smart process to a digital workspace; a type belongs to one workspace at a time, so attaching it here detaches it from its previous workspace. On PATCH the set is overwritten in full: send the complete list, or omit the key to leave the current set untouched; an empty list detaches every type. A value that names no type of this portal — an entityTypeId included — is refused with 400 UNKNOWN_TYPE_ID before the portal call, because Bitrix24 would otherwise drop it in silence and, the set being replaced in full, detach every type the request does not repeat. The check relies on the portal's type list: if that list is unavailable or incomplete, the write proceeds unchecked — compare typeIds in the response. Not accepted in filter or sort — crm.automatedsolution.list filters and orders by id and title only.",
        "itemSchema": {
          "type": "number"
        }
      }
    },
    "batch": ["create", "update", "delete"]
  }
}
```

## Error response example

401 — the API key is missing:

```json
{
  "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` | The `X-Api-Key` header was not passed |
| 401 | `TOKEN_MISSING` | The API key has no configured tokens |
| 403 | `SCOPE_DENIED` | The API key does not have the `crm` scope |
| 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 a workspace](/docs/entities/automated-solutions/create)
- [Update a workspace](/docs/entities/automated-solutions/update)
- [Digital workspaces](/docs/entities/automated-solutions)
- [Smart process type fields](/docs/entities/smart-processes/fields)
- [Entity API](/docs/entity-api)