Read and manage Pylon support issues, replies and internal notes, accounts, contacts, users, teams and tags, through the Pylon B2B support platform API.
Pylon ships in the w6w first-party pack. It declares 30 actions, 3 health checks, and the host runs its code in a sandbox that never sees the credential.
io.w6w.pylonPylon is a B2B customer support platform that unifies Slack, Microsoft Teams, email, chat and portal conversations into one issue queue tied to customer accounts. This app connects a workflow to its REST API with an API token, in either the US or the EU region.
A workflow can list, fetch, search, create, update and snooze issues, read an issue’s messages, threads and followers, send a customer-facing reply or post an internal note, and list the issue statuses. It can list, fetch, search, create and update accounts and contacts, look up users and teams, and manage tags.
The API wraps every record in {data, pagination, request_id}; this app unwraps it, returning each record directly and each list under a named key with nextCursor where Pylon paginates. Errors are reported with Pylon’s stable code. Health checks verify the token, whether the API answers, and Pylon’s own status page.
Three routes to the same 30 actions. The Workflow tab is generated from Pylon'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.
account-search Search accounts by a filter tree and/or fuzzy text, e.g. by domain, name or external ID.
account-update Update an account by its Pylon ID or external ID. Only the fields you set change.
contact-search Search contacts by a filter tree and/or fuzzy text, e.g. by email or account.
contact-update Update a contact by its Pylon ID or external ID. Only the fields you set change.
issue-create Create an issue with its first message. Needs an account or a requester. Unless a destination is set, the first message is an internal note and no customer is contacted.
issue-list List issues created within a time range of at most 365 days. Use Search Issues to filter by state, assignee, account or tag.
issue-note-create Post an internal note on an issue. It is not visible to the requester.
issue-reply Send a customer-facing reply on an issue, visible to the requester. Use Post Internal Note for a private one.
issue-search Search issues by a filter tree and/or fuzzy text, one cursor page at a time. Unlike List Issues it needs no time range.
issue-status-list List the organization's issue statuses, including custom ones. A status `slug` is a valid `state` for Update Issue.
issue-thread-list List an issue's threads. A thread's `id` is what Post Internal Note takes as its internal thread.
issue-update Change an issue's title, state, assignee, team, account, requester, tags or custom fields. Only the fields you set change.
me-get Return the organization and the user the API token belongs to. Handy for confirming a token and region.
message-list List an issue's messages, replies and internal notes, oldest first. With no limit and no cursor every message is returned. A message's top-level `id` is what Reply to Issue needs.
user-list List the organization's users (support agents). Deactivated users are left out unless asked for.
user-search Find users by email address. Email is the only field Pylon lets you filter users on.
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 Pylon's real ids.
{
"manifestVersion": "2",
"name": "pylon-example",
"steps": [
{
"id": "account-create",
"uses": {
"app": "io.w6w.pylon",
"action": "account-create",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"name": "<name>"
}
}
]
}account-create account-get account-list account-search account-update +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 Pylon, 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 Pylon. 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: "account-create",
payload: {
name: "<value>",
// accountType: "<value>",
// domains: "<value>",
// primaryDomain: "<value>",
// externalIds: "<value>",
// ownerId: "<value>",
// logoUrl: "<value>",
// tags: "<value>",
// customFields: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value); npm install -g @w6w/cli w6w run conn_YOUR_CONNECTION_ID --action account-create --payload '{"name":"<value>"}' Give an AI agent Pylon — without giving it Pylon'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.pylon#account-create",
"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 Pylon 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.
Pylon'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. Pylon itself is MIT, and the runtime that executes it is source-available (FSL).
Pylon declares its own checks, so its health is a property of the app rather than something the host guesses at.
status.usepylon.com (incident.io, Statuspage v2 shape). The `API` component decides; every other component is detail only.
Unauthenticated GET of /me on the connection's region host. Pylon's documented 401 authentication error is the expected healthy answer; token validity is the `auth:api-token` check's job.