First-party app
LiveChat LiveChat

LiveChat

Read and manage LiveChat chats, threads, customers, agents, groups and tags, and send messages into a chat.

stable Customer SupportCommunication

About

LiveChat ships in the w6w first-party pack. It declares 22 actions, 3 health checks, and the host runs its code in a sandbox that never sees the credential.

App id
io.w6w.livechat
Version
0.1.1
Author
w6w
Licence
MIT
Categories
Customer Support · Communication

Overview

LiveChat (by Text) is a live chat and customer-support platform. This app puts its Agent Chat and Configuration APIs into a workflow: start a chat, send a message or an internal note into it, transfer or close it, and tag its threads.

On the read side it lists active chats and searches the chat archive by text, date, customer, agent, group or tag, and reads a chat with its full event history. Customers can be looked up and updated, and the license’s agents, groups, tags and channels can be listed, so a workflow can route a conversation or enrich a record from the people and groups LiveChat already knows about.

Agent availability is covered too: read every agent’s routing status and flip one between accepting and not accepting chats, for example when a shift ends. Health checks track LiveChat’s own status page, keyed on its API component, plus an unauthenticated reachability probe of the API.

Build with LiveChat

Three routes to the same 22 actions. The Workflow tab is generated from LiveChat's own manifest and carries its real ids, so it is copy-pasteable; the Code and CLI examples are the same call for any action on any app, so every app-specific value in them is a blank you fill in.

Create tag

create-tag

Create a tag, optionally limited to groups (`POST /v3.6/configuration/action/create_tag`). Needs `tags--all:rw` or `tags--groups:rw`. Matching an existing name is case insensitive.

Close chat

deactivate-chat

Deactivate a chat by closing its open thread (`POST /v3.6/agent/action/deactivate_chat`). Messages can no longer be sent to that thread. Closing an already-closed chat is an error (`chat_inactive`), so this is not marked idempotent.

Delete tag

delete-tag

Delete a tag (`POST /v3.6/configuration/action/delete_tag`). Needs `tags--all:rw` or `tags--groups:rw`. The name is matched case sensitively here, unlike create.

Get agent

get-agent

One agent by id (`POST /v3.6/configuration/action/get_agent`). Needs `agents--my:ro` or `agents--all:ro`.

Get chat

get-chat

One chat with a thread and its events (`POST /v3.6/agent/action/get_chat`). Without a thread id LiveChat returns the latest thread.

Get customer

get-customer

A customer's profile, statistics, last visit and chat ids (`POST /v3.6/agent/action/get_customer`). Needs the `customers:ro` scope.

Get group

get-group

One group by id (`POST /v3.6/configuration/action/get_group`). Needs `groups--my:ro`, or `groups--all:ro` for groups the agent is not a member of.

List agents

list-agents

Every agent in the license (`POST /v3.6/configuration/action/list_agents`). Needs `agents--all:ro`. The call is not paginated.

List archived chats

list-archives

Search chat history by thread (`POST /v3.6/agent/action/list_archives`). The same chat can appear several times, once per matching thread; each item is a complete chat object.

List channels

list-channels

Channels that have had chat activity: `code` (the widget), `direct_link` and `integration` (`POST /v3.6/configuration/action/list_channels`). Needs no scope.

List chats

list-chats

Summaries of the chats the token can access (`POST /v3.6/agent/action/list_chats`). Filters go on the first request only; continue with the returned page id.

List groups

list-groups

Every group in the license (`POST /v3.6/configuration/action/list_groups`). Needs `groups--all:ro`. Group ids are integers; 0 is the default group.

List routing statuses

list-routing-statuses

Each agent's current chat-routing status, optionally for given groups only (`POST /v3.6/agent/action/list_routing_statuses`). Needs `agents--all:ro` and `agents-bot--all:ro`.

List tags

list-tags

Tags available in the given groups (`POST /v3.6/configuration/action/list_tags`). Needs `tags--all:ro` or `tags--groups:ro`. LiveChat requires the group filter.

List threads

list-threads

Threads of one chat, with their events (`POST /v3.6/agent/action/list_threads`). LiveChat returns only 3 threads per page unless `limit` is set.

Send message

send-event

Send a message (or any other event object) into a chat (`POST /v3.6/agent/action/send_event`). The sender must already be a user of the chat. Events with visibility `agents` are internal notes.

Set routing status

set-routing-status

Change whether an agent (or bot agent) receives chats (`POST /v3.6/agent/action/set_routing_status`). Without an agent id it changes the token's own agent. `offline` is valid for bot agents only.

Start chat

start-chat

Start a chat, optionally with a customer, extra agents and a first message (`POST /v3.6/agent/action/start_chat`). The token's own agent is the requester and is added automatically; up to 4 other agents and 1 customer may be listed.

Tag thread

tag-thread

Add a tag to a chat thread (`POST /v3.6/agent/action/tag_thread`). Tag names are case sensitive.

Transfer chat

transfer-chat

Transfer an active chat to agents or groups (`POST /v3.6/agent/action/transfer_chat`). Without a target the chat is transferred within its current group.

Untag thread

untag-thread

Remove a tag from a chat thread (`POST /v3.6/agent/action/untag_thread`). Tag names are case sensitive.

Update customer

update-customer

Update a customer's name, email, phone, avatar or session fields (`POST /v3.6/agent/action/update_customer`). Needs `customers:rw`. At least one field besides the id is required.

A workflow step names the app and the action, and the editor fills in the connection when you pick one. This is the Step shape from the workflow spec, carrying LiveChat's real ids.

{
  "manifestVersion": "2",
  "name": "livechat-example",
  "steps": [
    {
      "id": "create-tag",
      "uses": {
        "app": "io.w6w.livechat",
        "action": "create-tag",
        "connection": "conn_YOUR_CONNECTION_ID"
      },
      "with": {
        "name": "<name>"
      }
    }
  ]
}

Here are some of the things you can do

  • Create tag

    perform
    create-tag
  • Get agent

    read
    get-agent
  • Get chat

    read
    get-chat
  • Get customer

    read
    get-customer
  • Get group

    read
    get-group

+17 more actions available

Every app-specific value here is a blank you have to fill in. An app action is reached through the connection that authenticates it, so the address is a connection id, not the app id — and connections belong to your account, so a public page cannot know yours. Create one for LiveChat, then fill in the three blanks: conn_YOUR_CONNECTION_ID, the action key, and the parameters that action declares. The call itself is real — the shape is transcribed from the studio's own snippet builder, which prints the same kind of blanks — but nothing in it is specific to LiveChat. The Workflow tab is where this app's real ids are.

Install
npm install @w6w/sdk
yarn add @w6w/sdk
pnpm add @w6w/sdk
deno add npm:@w6w/sdk
Code
import { W6wClient, isActionRun } from "@w6w/sdk";

// Reads W6W_BASE_URL and W6W_TOKEN from the environment when omitted.
const client = new W6wClient();

const envelope = await client.run({
  urn: "conn_YOUR_CONNECTION_ID",
  action: "create-tag",
  payload: {
    name: "<value>",
    // groupIds: "<value>",
  },
});

if (isActionRun(envelope)) console.log(envelope.value);
Install the CLI
npm install -g @w6w/cli
CLI
w6w run conn_YOUR_CONNECTION_ID --action create-tag --payload '{"name":"<value>"}'

Give an AI agent LiveChat — without giving it LiveChat's credentials. One MCP endpoint exposes every app, function and workflow the caller is entitled to, as tools it can discover and run. Access is granted per team while we onboard.

One tool call
{
  "name": "w6w_invoke",
  "arguments": {
    "ref": "app:io.w6w.livechat#create-tag",
    "input": {
      "name": "<name>"
    }
  }
}

Every tool names its target with a single ref. The app: form above doesn't name a connection at all — the host resolves which of the caller's LiveChat connections to sign with, and refuses rather than guesses when the answer is ambiguous.

What the agent gets

Credentials it can't read

The token is attached host-side, at the moment of the call. It is never a tool argument, never in the model's context, and never in a transcript — so a prompt injection has nothing to exfiltrate.

A tool surface scoped to the caller

Tools are derived per end user from what that person has actually connected and is entitled to — not one shared bot identity carrying the union of everyone's access.

A durable workflow in one call

Multi-step work runs on the workflow engine and returns a run handle the agent can poll — retries, branching and state survive the conversation that started them.

Health-aware discovery

LiveChat's declared health checks are on the surface too, so an agent can tell "the vendor is down" from "your credential expired" before it burns a retry on either.

The MCP surface is part of the hosted platform. LiveChat itself is MIT, and the runtime that executes it is source-available (FSL).

Request MCP access

Health checks

LiveChat declares its own checks, so its health is a property of the app rather than something the host guesses at.

service

LiveChat platform status

Component status from status.livechat.com (incident.io, Statuspage-compatible JSON). The `API` component decides the verdict; the others are reported but never move it.

dependency

API reachability

Unauthenticated POST of configuration/action/list_channels. A schema-correct `error` envelope (HTTP 401, type `authentication`) is the expected healthy answer. Credential validity is the `auth:personal-access-token` check's job.

quota

API rate-limit headroom