## Create a to-do

`POST /v1/activity-todos`

Creates a "To-do" activity on a deal, lead, contact or company. Fields are passed flat at the JSON root, without a `fields` wrapper.

## Request fields (body)

| Field | Type | Required | Description |
|------|-----|:-----:|---------|
| `ownerTypeId` | number | yes | Type of the CRM object the activity belongs to. For a deal, `2` |
| `ownerId` | number | yes | CRM object ID. For a deal, an ID from [`GET /v1/deals`](/docs/entities/deals/list) |
| `deadline` | string | yes | Activity deadline in ISO 8601 format, for example `2026-11-02T12:00:00+00:00` |
| `title` | string | no | Activity title. Returned in the `subject` field of the response |
| `description` | string | no | Activity description |
| `responsibleId` | number | no | Responsible person ID. List: [`GET /v1/users`](/docs/entities/users/list). If omitted, the key's user becomes the responsible person |
| `parentActivityId` | number | no | ID of the activity the new one is linked to. The parent must belong to the same CRM object. Activities of an object: [`GET /v1/activities`](/docs/entities/activities/list) filtered by `ownerTypeId` and `ownerId` |
| `pingOffsets` | number[] | no | Reminders: integer minutes before the deadline, not less than `0` |
| `colorId` | string | no | Activity color: `default` or `1` to `7`. The color cannot be changed after creation |

The body accepts no other fields: an unknown field is rejected with `400 INVALID_PARAMS`.

## Examples

### curl — personal key

```bash
curl -X POST "https://vibecode.bitrix24.com/v1/activity-todos" \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "ownerTypeId": 2,
    "ownerId": 8845,
    "deadline": "2026-11-02T12:00:00+00:00",
    "title": "Review the contract",
    "description": "Call the customer"
  }'
```

### curl — OAuth application

```bash
curl -X POST "https://vibecode.bitrix24.com/v1/activity-todos" \
  -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "ownerTypeId": 2,
    "ownerId": 8845,
    "deadline": "2026-11-02T12:00:00+00:00",
    "title": "Review the contract",
    "description": "Call the customer"
  }'
```

### JavaScript — personal key

```javascript
const res = await fetch('https://vibecode.bitrix24.com/v1/activity-todos', {
  method: 'POST',
  headers: {
    'X-Api-Key': 'YOUR_API_KEY',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    ownerTypeId: 2,
    ownerId: 8845,
    deadline: '2026-11-02T12:00:00+00:00',
    title: 'Review the contract',
    description: 'Call the customer',
  }),
})

const { data } = await res.json()
console.log('To-do ID:', data.id)
```

### JavaScript — OAuth application

```javascript
const res = await fetch('https://vibecode.bitrix24.com/v1/activity-todos', {
  method: 'POST',
  headers: {
    'X-Api-Key': 'YOUR_APP_KEY',
    'Authorization': 'Bearer USER_SESSION_TOKEN',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    ownerTypeId: 2,
    ownerId: 8845,
    deadline: '2026-11-02T12:00:00+00:00',
    title: 'Review the contract',
    description: 'Call the customer',
  }),
})

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

## Response fields

The response is HTTP `201` with the created activity, read back after the write. The shape is the same as in [`GET /v1/activities/:id`](/docs/entities/activities/get).

| Field | Type | Description |
|------|-----|---------|
| `success` | boolean | `true` on success |
| `data` | object | The created activity, all fields: [Activity fields](/docs/entities/activities/fields) |
| `data.id` | number | Activity ID. Use it to read the activity via [`GET /v1/activities/:id`](/docs/entities/activities/get) and to change it via [`PATCH /v1/activity-todos/:id`](./update.md) |
| `data.providerId` | string | Always `CRM_TODO` |
| `data.subject` | string | Title from the request's `title` field |
| `data.deadline` | string | Activity deadline in UTC |
| `data.associatedEntityId` | number | Parent activity ID from `parentActivityId`, or `0` without a parent |
| `data.completed` | boolean | Whether the activity is completed. `false` for a new activity |

## Response example

Main fields are shown. Full list: [Activity fields](/docs/entities/activities/fields).

```json
{
  "success": true,
  "data": {
    "id": 8379,
    "ownerId": 8845,
    "ownerTypeId": 2,
    "typeId": 6,
    "providerId": "CRM_TODO",
    "providerTypeId": "TODO",
    "associatedEntityId": 0,
    "subject": "Review the contract",
    "deadline": "2026-11-02T12:00:00.000Z",
    "completed": false,
    "status": 1,
    "responsibleId": 1317,
    "description": "Call the customer"
  }
}
```

## Error response example

400 — the parent activity belongs to a different CRM object:

```json
{
  "success": false,
  "error": {
    "code": "INVALID_PARAMS",
    "message": "Parent activity is not bound to the requested CRM owner"
  }
}
```

## Errors

| HTTP | Code | Description |
|------|-----|----------|
| 400 | `INVALID_PARAMS` | Body validation failed: `ownerTypeId`, `ownerId` or `deadline` is missing, an ID field is not a positive integer, `title` or `description` is not a string, the deadline is not in ISO 8601 format, the color is outside the palette, `pingOffsets` is not an array of non-negative integers, or the body has an unknown field |
| 400 | `INVALID_PARAMS` | The parent activity from `parentActivityId` belongs to a different CRM object |
| 400 | `MISSING_REQUIRED_FIELDS` | The request body is not a JSON object |
| 422 | `ACTIVITY_PARENT_NOT_APPLIED` | The activity was created, but without the link to the parent. The new activity ID is in `error.createdId`: check it via [`GET /v1/activities/:id`](/docs/entities/activities/get) along with the parent activity instead of sending `POST` again, since a retry creates a second activity |
| 404 | `ENTITY_NOT_FOUND` | The activity in `parentActivityId` does not exist. No activity is created |
| 502 | `BITRIX_ERROR` | The parent activity's bindings could not be read, or Bitrix24 did not return the created activity's ID. In the second case, check the object's activity list before retrying the request |
| 502 | `ACTIVITY_CREATED_READ_FAILED` | The activity was created, but reading it back after the write failed. The new activity ID is in `error.createdId`: check it via [`GET /v1/activities/:id`](/docs/entities/activities/get) instead of sending `POST` again, since a retry creates a second activity |
| 403 | `WRITE_BLOCKED_READONLY_KEY` | The key is read-only |
| 403 | `SCOPE_DENIED` | The key has no `crm` scope |
| 401 | `TOKEN_MISSING` | The key has no Bitrix24 connection |

Full list of common API errors: [Errors](/docs/errors).

## Known specifics

**The parent is completed.** The activity specified in `parentActivityId` becomes completed once the new one is created: `completed: true`, `status: 2`.

## See also

- [Update a to-do](./update.md)
- [Get an activity](/docs/entities/activities/get)
- [List activities](/docs/entities/activities/list)
- [Complete an activity](/docs/entities/activities/complete)
- [CRM to-do activities](../todos.md)