How to turn a WhatsApp conversation into a WACRM task

A task in WACRM always starts from a conversation: a customer asks something your team needs to follow up on, and rather than leaving a note in your head, you turn that message into a task right there in the Inbox. This tutorial covers what that screen actually does today, how to do the same thing (plus assignment) through the API, and where the bridge back to WACRM’s underlying Work system still needs a request to WACRM rather than a toggle you can flip yourself.

What you need before you start

• A WACRM Workspace account with at least one project and at least one conversation in Conversations → Inbox.
• For the API steps only: curl (or any HTTP client that can set a header), and an API key from Developer / API & MCP.

Create a task from the Inbox

1. Open Conversations → Inbox and select the conversation you want to follow up on.
2. In the side panel, find the Tasks card, below the conversation’s Contact card (and below the Consent and Billing cards too, when those show for the contact). It starts empty with No tasks yet until you create the first one.
3. Click Create task. A dialog opens asking for a Title (required) and a Due date (optional).
4. Fill in a title and click Create task in the dialog.

The dialog closes and the new task appears at the top of the list immediately — the card re-fetches right after a successful create, so there’s nothing to refresh by hand. Each row shows the task’s title, a status chip, and when it was created. A new task always starts with status open (shown as a warning-colored chip); done shows in green, cancelled in a neutral gray.

There is no field for a note or description here — only title and due date are saved, because that’s all this dialog sends today. There is also no assignee picker on this screen; assignment is API-only, see below.

Create and list tasks through the API

Everything the Tasks card does is backed by two Core API endpoints, scoped per conversation:

POST /v1/conversations/{conversation}/tasks      work:write
GET  /v1/conversations/{conversation}/tasks       work:read

work:read/work:write are selectable when you create a key — in Developer / API & MCP, click Create key, open Restrict what this key can do (advanced), and tick work:read/work:write under WhatsApp CRM scopes (work:write needs a Secret key). Creating keys and restricting scopes depends on your plan — Workspace shows an upgrade notice if yours doesn’t include it. A key minted without them answers 403 insufficient_scope on these calls — that’s expected, not a bug; mint a new key with the scopes ticked instead.

Create a task, with assignment

POST .../tasks requires an Idempotency-Key header, same convention as POST /v1/messages: retrying the same request with the same key replays the original task instead of creating a second one, which makes it safe to retry after a timeout.

curl -s -X POST "https://api.wacrm.ai/v1/conversations/your-conversation-uuid/tasks" \
  -H "Authorization: Bearer sk_live_your_scoped_key" \
  -H "Idempotency-Key: a-key-you-generate-once-per-task" \
  -H "Content-Type: application/json" \
  -d '{"title": "Call back about refund", "due_at": "2026-11-10", "assignee_ref": "staff-jane"}'

{
  "data": {
    "id": "0e2b1c9a-...-task-uuid",
    "conversation_id": "your-conversation-uuid",
    "title": "Call back about refund",
    "due_at": "2026-11-10T00:00:00+00:00",
    "assignee_ref": "staff-jane",
    "status": "open",
    "external_ref": null,
    "created_at": "2026-11-06T09:00:00+00:00"
  }
}

due_at and assignee_ref are both optional. assignee_ref is a free-text string your own system defines — WACRM doesn’t validate it against a staff list, since Workspace has no staff-assignment concept of its own yet for this screen to draw from. external_ref stays null until the Work bridge delivers the task to the other side.

List a conversation’s tasks

curl -s "https://api.wacrm.ai/v1/conversations/your-conversation-uuid/tasks" \
  -H "Authorization: Bearer sk_live_your_scoped_key"

This is the same call the Inbox Tasks card itself makes, so the response always matches what you’d see on screen — newest first, with the same fields as the create response above (8 fields each).

See a task’s status come back

Once a task reaches the Work side, a status change there (someone marks it done, or cancels it) is meant to flow back to WACRM through a signed callback, POST /v1/work/callbacks, and update the task’s status to done or cancelled. From the Inbox, that shows up as the task’s chip changing color the next time you open the conversation fresh — there’s no live polling on this card and no refetch just from looking at the same conversation again, so a status change made while you’re already looking at it won’t appear until you switch to another conversation and back.

Two things have to be true on WACRM’s side for that round trip to actually happen, and neither is something you can turn on yourself from Workspace:

• The Work bridge has to be enabled. WACRM switches it on for the whole service, not per workspace, and it’s off today; a disabled bridge still saves your task and queues its delivery, it just never reaches the other side or gets an external_ref until WACRM turns it on.
• The Work side has to send the status webhook. Today, a task’s status only ever changes through that one callback — there’s no WACRM-side polling fallback. If a task you created looks stuck on open even though it was handled elsewhere, that’s the known gap, not something you’re missing in Workspace.

What works today vs. what needs WACRM

Ready to put this into practice? Request early access to get a Workspace, or have WACRM’s team set up your project for you with Quick Setup.