Enrich Missive conversations with posts, drafts and comments; manage contacts, shared labels, teams and tasks.
Missive ships in the w6w first-party pack. It declares 42 actions, 2 health checks, and the host runs its code in a sandbox that never sees the credential.
io.w6w.missiveMissive is a shared team inbox that unifies email, SMS, WhatsApp, live chat and social messages into one collaborative workspace. Its public REST API is deliberately narrow next to the product surface it fronts: no inbox browsing beyond a handful of read endpoints, but a solid path for the two things most integrations actually need — inserting content into a conversation (drafts that send real messages, posts that leave an automation’s trace, comments) and keeping the surrounding data (contacts, contact books, shared labels, teams, users, tasks, canned responses) in sync with an outside system.
Every endpoint here is read straight off Missive’s own GitBook-hosted API reference (missiveapp.com/docs/developers/rest-api), not inferred from a sibling integration. The app covers conversations (list, get, update, merge, and reading their messages/comments/drafts/posts), drafts (create — including send-immediately and scheduled send — and delete), messages (create for custom channels, get, list by Message-ID), posts (create and delete), canned responses (full CRUD), contacts and contact books/groups (full CRUD on contacts, listing books and groups), shared labels (create, update, list), teams and users (list, create/update teams), tasks (full CRUD), webhook subscriptions (create/delete), organizations (list) and analytics reports (create + poll).
Missive tokens are personal, not scoped, and not organization-bound — a single token reaches every account and shared conversation its owner can see in the app. Health checks reflect that plainly: there is no machine-readable status feed to probe (Missive’s own status page runs on PagerDuty’s status-page product behind a private, authenticated API) and no advance-of-refusal quota signal (rate-limit headers are only ever returned on the 429 itself), so both are declared absent rather than guessed at.
Three routes to the same 42 actions. The Workflow tab is generated from Missive'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.
analytics-report-create Start generating an analytics report for a period. Poll Get Analytics Report with the returned ID to fetch the data — reports usually finish within a few seconds and expire 60 seconds after completion. Requires a Productive or Business plan; filters require Business.
analytics-report-get Fetch a report's data using the ID from Create Analytics Report. Missive suggests waiting 5 seconds after creation, then retrying every 5 seconds. A completed report expires 60 seconds after completion; an incomplete, expired, or unknown report answers an empty 404.
contact-group-list List contact groups or organizations linked to a contact book.
contact-list List or search contacts in a contact book, or sync ones modified since a point in time.
contact-update Update a contact. Only the fields you set are changed — EXCEPT Contact Infos and Memberships, which replace the entire array when set: omit an item you want to keep and it is deleted from the contact.
conversation-comments-list List internal comments on a conversation, newest first.
conversation-drafts-list List draft messages in a conversation, newest first.
conversation-get Fetch a conversation by ID. If it was merged into another conversation, the response's ID may differ from the one requested.
conversation-list List conversations in one mailbox view (Inbox, a shared label, a team inbox, etc.), newest activity first.
conversation-merge Merge one conversation into another. All messages, comments, and other entries move to the surviving conversation, which is marked as replaced. The surviving conversation's ID may differ from either the source or the requested target due to internal swapping.
conversation-messages-list List delivered (non-draft) messages in a conversation, newest first.
conversation-posts-list List posts (integration/automation entries) in a conversation, newest first.
conversation-update Close, reopen, move, assign, label, recolor, or rename a conversation silently — no post is added. Label-change rules still run.
draft-create Create a draft — or, with Send enabled, send it immediately — as an email, SMS, WhatsApp, or Missive Live Chat message. Append to an existing conversation with Conversation ID or References, or start a new one.
message-create Simulate a message received on a custom channel. Not for sending email or replies — use Create Draft with Send enabled for that.
message-get Fetch one or more messages by ID, including headers, body, and attachments. Pass comma-separated IDs to fetch several in one call.
message-list Look up messages by the email Message-ID header. Usually returns one match; up to the latest 10 if a non-compliant sender reused the same Message-ID.
post-create Insert a post into a conversation — the recommended way for an integration to leave a visible trace while closing, moving, assigning, or labeling a conversation. Requires a notification, and at least one of Text, Markdown, or Attachments.
post-delete Delete a post from a conversation. For shared conversations, the token must belong to an organization owner or admin.
response-create Create a canned/template response, shared with an organization or scoped to a single user.
response-delete Delete one or more canned responses. Organization-restricted response management (enterprise) limits this to admins/owners; externally-sourced responses (e.g. WhatsApp templates) cannot be deleted here.
response-list List canned responses (Missive's saved-reply templates) for the authenticated user.
response-update Update a canned response. Only the fields you set change — except Attachments, which replaces the entire array when set. Responses created by an external integration (e.g. WhatsApp templates) cannot be updated.
shared-label-list List shared labels in organizations the authenticated user has access to.
shared-label-update Update a shared label. Visibility and sharing fields require an admin/owner token; name/color/parent do not.
task-create Create a standalone task (needs Team ID or Assignees) or a conversation subtask (needs Subtask + Conversation ID or References). Created tasks appear only in the Tasks view.
team-update Update a team. Requires an admin or owner token. Only the fields you set change.
user-list List users in organizations the authenticated user is part of. Missive's API does not expose user status (availability/away/out of office).
webhook-create Subscribe a URL to a Missive event. Creates a Missive rule with a webhook action under the hood, editable later in Rules settings.
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 Missive's real ids.
{
"manifestVersion": "2",
"name": "missive-example",
"steps": [
{
"id": "analytics-report-create",
"uses": {
"app": "io.w6w.missive",
"action": "analytics-report-create",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"organization": "<organization>",
"start": "<start>",
"end": "<end>"
}
}
]
}analytics-report-create analytics-report-get contact-book-list contact-create contact-get +37 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 Missive, 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 Missive. The Workflow tab is where this app's
real ids are.
npm install @w6w/sdkyarn add @w6w/sdkpnpm add @w6w/sdkdeno add npm:@w6w/sdkimport { 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: "analytics-report-create",
payload: {
organization: "<value>",
start: "<value>",
end: "<value>",
// timeZone: "<value>",
// teams: "<value>",
// users: "<value>",
// accounts: "<value>",
// accountTypes: "<value>",
// sharedLabels: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value); npm install -g @w6w/cli w6w run conn_YOUR_CONNECTION_ID --action analytics-report-create --payload '{"organization":"<value>","start":"<value>","end":"<value>"}' Give an AI agent Missive — without giving it Missive'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.missive#analytics-report-create",
"input": {
"organization": "<organization>",
"start": "<start>",
"end": "<end>"
}
}
}
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 Missive connections to sign
with, and refuses rather than guesses when the answer is ambiguous.
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.
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.
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.
Missive'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. Missive itself is MIT, and the runtime that executes it is source-available (FSL).
Missive declares its own checks, so its health is a property of the app rather than something the host guesses at.
Missive publishes a real status page at status.missiveapp.com, but it runs on PagerDuty's status-page product behind a realtime (Ably) channel and an authenticated api.pagerduty.com backend — there is no static JSON/Atom/RSS feed this app can read anonymously, so the absence is declared rather than guessed at.
Missive documents its rate-limit headers (Retry-After, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) as accompanying only the 429 refusal itself, never an ordinary response — there is nothing to read ahead of a rejection.