## Update a template

`PATCH /v1/bizproc-templates/:id`

Updates a business process template uploaded by the same application. Fields are passed flat at the JSON root — without a `fields` wrapper.

## Parameters

| Parameter | Type | Req. | Description |
|----------|-----|:-----:|---------|
| `id` (path) | number | yes | Template identifier. Source: [`GET /v1/bizproc-templates`](./list.md) |

## Request fields (body)

Four fields can be changed. The remaining fields of the record are set when the file is uploaded and are not affected by an update request.

| Field | Type | Description |
|------|-----|---------|
| `name` | string | Template name |
| `description` | string | Template description |
| `autoExecute` | number | Autostart condition: `0` — no autostart, `1` — on document creation, `2` — on change, `3` — on creation and change |
| `templateData` | array | New template file as two elements — the file name and its contents in base64 |

## Examples

Only an authorization key can update templates — both examples send the authorization key and the `Authorization: Bearer` header. The session token is issued by OAuth authorization, is valid for 24 hours, and cannot be renewed — [Passing the key](/docs/keys-auth#passing-the-key).

### curl — authorization key

```bash
curl -X PATCH "https://vibecode.bitrix24.com/v1/bizproc-templates/1215" \
  -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Deal approval — version 2",
    "autoExecute": 1
  }'
```

### JavaScript — authorization key

```javascript
const res = await fetch('https://vibecode.bitrix24.com/v1/bizproc-templates/1215', {
  method: 'PATCH',
  headers: {
    'X-Api-Key': 'YOUR_APP_KEY',
    'Authorization': 'Bearer USER_SESSION_TOKEN',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    name: 'Deal approval — version 2',
    autoExecute: 1,
  }),
})

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

## Response fields

| Field | Type | Description |
|------|-----|---------|
| `success` | boolean | Always `true` on success |
| `data.id` | string | Identifier of the updated template, as a string |

## Response example

```json
{
  "success": true,
  "data": {
    "id": 1215
  }
}
```

## Error response example

422 — the template was uploaded by another application or created in the Bitrix24 designer:

```json
{
  "success": false,
  "error": {
    "code": "BITRIX_ERROR",
    "message": "You can update ONLY templates created by current application"
  }
}
```

## Errors

| HTTP | Code | Description |
|------|-----|----------|
| 422 | `BITRIX_ERROR` | The template was uploaded by another application — message `You can update ONLY templates created by current application` |
| 422 | `BITRIX_ERROR` | No template with the given `id` — message `Workflow template not found.`, the `b24Code` field contains `ERROR_TEMPLATE_NOT_FOUND` |
| 400 | `EMPTY_UPDATE_BODY` | The request body is empty — pass at least one field |
| 400 | `READONLY_FIELD` | A read-only field was passed in the body, for example `id` |
| 403 | `OAUTH_REQUIRED` | The request was sent with an API key. Only an authorization key can update templates |
| 401 | `TOKEN_MISSING` | Authorization key without the `Authorization: Bearer` header |
| 401 | `WRONG_AUTH_SCHEME` | The authorization key was sent in the `Authorization: Bearer` header. The key goes in `X-Api-Key`, while `Authorization: Bearer` carries the session token |
| 401 | `INVALID_SESSION` | The session token has expired or is invalid — authorize again |
| 403 | `SCOPE_DENIED` | The key lacks the `bizproc` scope |

On a Bitrix24-side error the `error` object gains a `b24Code` field — the machine-readable reason code.

The full list of common API errors — [Errors](/docs/errors).

## Known specifics

**Only your own templates can be updated.** You can change a template uploaded by the same application whose authorization key is used to send the request. Templates from the Bitrix24 designer and templates of other applications return `422` and remain unchanged.

**`documentType` cannot be changed after upload.** The schema at [`GET /v1/bizproc-templates/fields`](./fields.md) marks the field `readonly: false`, but an update request applies only the four fields from the table above — the document type is set when the file is uploaded. A request carrying `documentType` returns `200` and leaves the value unchanged.

**A field name outside the list above does not raise an error.** The request returns `200`, and the value is not applied. Check the result by reading the record through [`GET /v1/bizproc-templates`](./list.md) with a filter by `id`.

**Replacing the file marks the template as changed.** After `templateData` is updated, the `isModified` field in the list response becomes `true`.

## See also

- [Template list](/docs/entities/bizproc-templates/list)
- [Template fields](/docs/entities/bizproc-templates/fields)
- [Upload a template](/docs/entities/bizproc-templates/create)
- [Delete a template](/docs/entities/bizproc-templates/delete)
- [Keys and authorization](/docs/keys-auth)