First-party app
Front

Front

Work a Front shared inbox — find conversations, reply, comment, tag, assign, snooze, and keep the contacts behind them current.

stable Customer SupportCommunicationProductivity

About

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

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

Overview

Front centers a team’s shared inbox — every channel a customer might reach out through, routed into one place — and this app works that inbox from a workflow: find and search conversations, reply to the customer or add an internal comment for the team, tag, assign and snooze conversations, and keep the contact record behind each one current.

Replying and commenting are deliberately separate actions, because Front keeps the customer conversation and the team’s internal discussion in the same thread, and getting them confused sends internal notes to a customer. Tags and followers can be added or removed without touching the rest of a conversation’s state, and updates only replace what’s explicitly changed rather than defaulting to a full overwrite.

Beyond conversations, this app lists inboxes, channels, teammates and tags, and reads or writes contact records and their notes — enough to run a support or shared-inbox workflow end to end without leaving Front’s own conversation model behind.

Build with Front

Three routes to the same 30 actions. The Workflow tab is generated from Front'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.

List channels

channel-list

The channels messages can be sent from — address, type and id. Send Message needs one of these ids.

List a contact's conversations

contact-conversation-list

Every conversation with one person, across all their handles and channels. Accepts an `alt:email:…` alias, so an address is enough.

Create contact

contact-create

Create a contact. At least one handle is required — without one, Front cannot match the next message to this person and will make a second contact.

Get contact

contact-get

One contact by id — or by handle, using an `alt:email:…` / `alt:phone:…` alias, which is the only way to look a person up by address.

List contacts

contact-list

Contacts, optionally only those changed inside a time window — the incremental-sync filter, since Front offers no name or email filter here.

Add contact note

contact-note-add

Attach a note to the person, visible beside every conversation they open — unlike a comment, which stays on one thread.

Update contact

contact-update

Change a contact's name, description, links, lists or custom fields. Handles are not editable here — they are identities, added and removed individually.

Assign conversation

conversation-assign

Give a conversation to a teammate, or unassign it. Accepts a teammate id or an `alt:email:…` alias.

Add internal comment

conversation-comment-add

Post an internal note on a conversation. The team sees it; the customer never does — unlike Reply, which sends.

List comments

conversation-comment-list

The internal comments on a conversation — what the team said, not the customer.

Create discussion or task

conversation-create

An internal thread — a discussion or a task. Comment-only: no customer is on it and no message can be sent into it. Use Send Message to start a customer conversation.

List conversation events

conversation-event-list

What happened to a conversation and when — assignments, tags, archives, reopens. The history the conversation object does not keep.

Add followers

conversation-follower-add

Subscribe teammates to a conversation's activity without giving it to them — the non-destructive half of an escalation.

Remove followers

conversation-follower-remove

Unsubscribe teammates from a conversation's activity.

Get conversation

conversation-get

One conversation's status, assignee, tags, recipient and custom fields. Messages are a separate call.

List conversations

conversation-list

Conversations across the company, newest activity first. Filter by status — open work is `assigned` plus `unassigned`, which are two statuses rather than one.

List messages

conversation-message-list

The customer-visible messages on a conversation. Internal comments are a separate collection — List Comments reads those.

Reply to conversation

conversation-reply

Send a message into an existing conversation. Front archives on reply by default — this action does not, and always says which it means.

Search conversations

conversation-search

Front's search syntax — `is:open`, `tag:`, `from:`, `inbox:`, free text. Rate limited at 40% of the company's allowance, so search once and page rather than searching per row.

Snooze conversation

conversation-snooze

Take a conversation out of the queue until a stated time — or, with no time, put it back now. The reminder belongs to a teammate, whom Front requires you to name.

Add tags to conversation

conversation-tag-add

Add one or more existing tags, leaving the conversation's other tags alone. Ids, not names — List Tags maps between them.

Remove tags from conversation

conversation-tag-remove

Take one or more tags off a conversation, leaving the others in place.

Update conversation

conversation-update

Change a conversation's status, inbox, assignee or custom fields. Tags are deliberately not here — Front's tag field replaces the whole set, so use Add/Remove Tag instead.

List an inbox's conversations

inbox-conversation-list

One inbox's queue, filtered by status at Front rather than after the fact — the cheap way to ask 'what is unassigned in Support'.

List inboxes

inbox-list

The shared inboxes this token can see, with the ids other actions ask for. An inbox holds channels; it is not one itself.

Get message

message-get

One message in full — body, author, recipients and attachment metadata.

Send message

message-send

Send a new outbound message through a channel, starting a conversation. Recipients are handles (address, phone number), not contact ids.

List ticket statuses

status-list

Named ticket statuses and their ids, for companies with ticketing enabled. Empty when it is not — which is an answer, not a failure.

List tags

tag-list

The company's tags, mapping names to the ids Add/Remove Tags need. Company tags only — not one teammate's private labels.

List teammates

teammate-list

The company's teammates and their ids — including who is available, which is what stops a round-robin assigning to somebody who is away.

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 Front's real ids.

{
  "manifestVersion": "2",
  "name": "front-example",
  "steps": [
    {
      "id": "contact-conversation-list",
      "uses": {
        "app": "io.w6w.front",
        "action": "contact-conversation-list",
        "connection": "conn_YOUR_CONNECTION_ID"
      },
      "with": {
        "contactId": "<contactId>"
      }
    }
  ]
}

Here are some of the things you can do

  • List a contact's conversations

    read
    contact-conversation-list
  • List channels

    read
    channel-list
  • Create contact

    perform
    contact-create
  • Get contact

    read
    contact-get
  • List contacts

    read
    contact-list

+25 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 Front, 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 Front. 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: "contact-conversation-list",
  payload: {
    contactId: "<value>",
    // statuses: "<value>",
    // returnAll: "<value>",
    // limit: "<value>",
  },
});

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

Give an AI agent Front — without giving it Front'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.front#contact-conversation-list",
    "input": {
      "contactId": "<contactId>"
    }
  }
}

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 Front 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

Front'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. Front itself is MIT, and the runtime that executes it is source-available (FSL).

Request MCP access

Health checks

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

service

Front platform status

Front's Statuspage, split in two: the API components this app calls, and the message channels a reply goes out through — a dead channel is a partial failure, not an outage.

quota

API request headroom

Front's per-minute allowance and the 10-minute burst bucket behind it, read from the rate-limit headers on a scope-free GET /me.