Send and read texts, manage calls, contacts and tasks, and subscribe to webhooks on the Quo (formerly OpenPhone) business phone system.
Quo ships in the w6w first-party pack. It declares 43 actions, 2 health checks, and the host runs its code in a sandbox that never sees the credential.
io.w6w.quoQuo (rebranded from OpenPhone in 2026 — same product and API, openphone.com now redirects to quo.com) is a business phone system: shared numbers, calling, texting, voicemail, contacts and tasks for a whole workspace.
This app covers Quo’s full public REST API v1: phone numbers, sending and listing text messages, listing and reading calls (plus their AI-generated summaries, transcripts, voicemails and recordings), reading and managing contacts and their custom fields, managing the shared inbox (conversations: list and mark done/open/read), a task manager (create, update, complete, reopen, assign, due dates, link to a conversation), workspace users, and the beta webhook API for message/call/call-summary/call-transcript event subscriptions.
Authentication is a single per-workspace API key sent as a raw Authorization header — Quo’s own docs are explicit that there is no Bearer prefix.
Three routes to the same 43 actions. The Workflow tab is generated from Quo'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.
call-list Retrieve a paginated list of calls between a Quo number and one other number (1:1 only — unlike List Messages, this endpoint does not support group participants).
call-summary-get Get the AI-generated summary of a call by its unique call ID. Only available on Business and Scale plans; supports both regular calls and calls handled by Sona.
call-transcript-get Get the transcript of a call by its unique call ID. Only available on Business and Scale plans; supports both regular calls and calls handled by Sona.
call-voicemail-get Get the voicemail associated with a call. Fields are null while the recording is still processing.
contact-custom-field-list List this workspace's custom contact field definitions. Fields are defined in the Quo app only — this endpoint is read-only.
contact-list Retrieve a paginated list of contacts, optionally filtered by external ID and/or source. Returns all contacts when no filters are given.
contact-update Replace a contact's fields. This REPLACES rather than merges: always send the full set of emails, phone numbers and custom fields you want the contact to have — any you omit are deleted.
conversation-list Retrieve a paginated list of shared-inbox conversations, newest activity first. Can be filtered by user and/or phone number(s); defaults to every conversation in the workspace.
conversation-mark-as-done Mark a conversation as done, removing it from the inbox without sending a message.
conversation-mark-as-open Mark a conversation as open, returning it to the inbox without sending a message.
conversation-mark-as-read Mark a conversation as read, clearing its unread indicator without sending a message.
message-list Retrieve a chronological, paginated list of messages between a Quo number and up to 10 participants.
message-send Send a text message from a Quo number to up to 10 recipients (more than one recipient sends a single group message).
phone-number-list Retrieve every phone number and its users in the Quo workspace. Not paginated.
task-create Create a task linked to a phone number, conversation, or conversation activity. Provide exactly one of Phone Number ID, Conversation ID or Activity ID.
task-update Update a task's title and description. To change due date, assignment or linked conversation, use the dedicated actions for those.
webhook-create-call Create a webhook that triggers on call events (completed/ringing/recording completed).
webhook-create-call-summary Create a webhook that triggers when a call summary finishes generating.
webhook-create-call-transcript Create a webhook that triggers when a call transcript finishes processing.
webhook-create-message Create a webhook that triggers on message events (received/delivered).
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 Quo's real ids.
{
"manifestVersion": "2",
"name": "quo-example",
"steps": [
{
"id": "call-get",
"uses": {
"app": "io.w6w.quo",
"action": "call-get",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"callId": "<callId>"
}
}
]
}call-get call-list call-recordings-get call-summary-get call-transcript-get +38 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 Quo, 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 Quo. 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: "call-get",
payload: {
callId: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value); npm install -g @w6w/cli w6w run conn_YOUR_CONNECTION_ID --action call-get --payload '{"callId":"<value>"}' Give an AI agent Quo — without giving it Quo'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.quo#call-get",
"input": {
"callId": "<callId>"
}
}
}
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 Quo 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.
Quo'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. Quo itself is MIT, and the runtime that executes it is source-available (FSL).
Quo declares its own checks, so its health is a property of the app rather than something the host guesses at.
Atlassian Statuspage rollup for status.quo.com, with per-component detail. Unauthenticated and unsigned.
Reads Quo's IETF-draft `ratelimit`/`ratelimit-policy` response headers — a flat 10 requests/second per API key, undocumented but present on every response measured.