tasks.task.add — Create Bitrix24 Tasks via API

What tasks.task.add does

Creates tasks in the task/project module — the operational work layer. Integrations use it to turn CRM and external events into assigned, deadlined work: onboarding checklists after a won deal, document collection, delivery steps.

Business use cases

Won deal → onboarding/delivery task package
Document-collection tasks from application systems
SLA follow-up tasks created by external monitors
Recurring operational work generated from schedules

Typical fields and parameters

TITLE — Task name
RESPONSIBLE_ID — Assignee (required)
DEADLINE — ISO datetime; tasks without deadlines drift forever
CREATED_BY — Author shown; use the service account for traceability
UF_CRM_TASK — CRM bindings: array like ['L_20517','D_3120','C_512'] (lead/deal/contact prefixes) — makes the task visible on the CRM record
GROUP_ID — Project/workgroup placement
CHECKLIST — Add via tasks.api after creation or task.checklistitem methods

Example workflow

ONCRMDEALUPDATE event: deal 3120 moved to WON
Worker creates three tasks via batch: contract prep (legal), kickoff call (account manager), portal setup (ops)
Each bound to the deal via UF_CRM_TASK ['D_3120'] with staggered deadlines
Delivery team works from tasks; sales sees progress on the deal card

Example request

POST .../tasks.task.add.json

{
  "fields": {
    "TITLE": "Kickoff call — Order #8842",
    "RESPONSIBLE_ID": 12,
    "DEADLINE": "2026-07-10T10:00:00+04:00",
    "DESCRIPTION": "Schedule and run kickoff. Confirm scope from deal notes.",
    "UF_CRM_TASK": ["D_3120"],
    "GROUP_ID": 5
  }
}

Example response

{
  "result": { "task": { "id": 7741, "title": "Kickoff call — Order #8842", ... } },
  "time": { ... }
}

Field mapping notes

UF_CRM_TASK prefixes: L_ lead, D_ deal, C_ contact, CO_ company — wrong prefix silently binds nothing
tasks.task.* methods return nested result.task objects, not bare IDs
DEADLINE respects the portal timezone rules; send explicit offsets

Security notes

Task descriptions often carry client details — same data-minimization discipline as CRM fields

Common errors

Task invisible on the deal card — UF_CRM_TASK missing or wrong prefix format
'Access denied' for GROUP_ID — Service account is not a member of the workgroup — add it or drop the group placement
Duplicate task packages on event retries — Idempotency: check for existing open tasks bound to the record with the same title/marker before creating

Production implementation tips

Create task packages with batch and a template table — changing the onboarding checklist should be a data change, not a code change
Set both RESPONSIBLE_ID and a realistic DEADLINE — undated integration tasks train teams to ignore them

Webhook or OAuth app?

Follows the parent integration; note the additional task scope on whichever auth you use.

Full decision guide: webhook vs OAuth app in Bitrix24.

When to use a queue worker

Task packages from events belong in the same worker pipeline as the event processing itself.

How Tech Titan can help

Tech Titan builds production Bitrix24 integrations around tasks.task.add and its siblings — with authentication, field mapping, queue workers, retry logic, duplicate handling, and structured logs as standard. If this method is on your critical path, bring the requirement to a free audit call and leave with an architecture sketch.

Book Free CRM Audit or Demo API Development service

Frequently asked questions

How do I create a task linked to a deal?

tasks.task.add with UF_CRM_TASK: ['D_' + dealId]. The task then appears on the deal card's task list.

Can I create recurring tasks via API?

Templates with recurrence are the native mechanism; via pure API you typically schedule creation from your own cron/queue, which also gives you more control over skip/holiday logic.