First-party app
Pylon Pylon

Pylon

Read and manage Pylon support issues, replies and internal notes, accounts, contacts, users, teams and tags, through the Pylon B2B support platform API.

stable Customer SupportCustomer Relationship Management

About

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.

App id
io.w6w.pylon
Version
0.1.0
Author
w6w
Licence
MIT
Categories
Customer Support · Customer Relationship Management

Overview

Pylon 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.

Build with Pylon

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.

Create Account

account-create

Create a customer, partner, community or internal account.

Get Account

account-get

Fetch one account by its Pylon ID or one of its external IDs.

List Accounts

account-list

List accounts one cursor page at a time.

Search Accounts

account-search

Search accounts by a filter tree and/or fuzzy text, e.g. by domain, name or external ID.

Update Account

account-update

Update an account by its Pylon ID or external ID. Only the fields you set change.

Create Contact

contact-create

Create a contact, optionally attached to an account.

Get Contact

contact-get

Fetch one contact by its Pylon ID or one of its external IDs.

List Contacts

contact-list

List contacts one cursor page at a time.

Search Contacts

contact-search

Search contacts by a filter tree and/or fuzzy text, e.g. by email or account.

Update Contact

contact-update

Update a contact by its Pylon ID or external ID. Only the fields you set change.

Create Issue

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.

Get Issue

issue-get

Fetch one issue by its ID or issue number.

List Issues

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.

Post Internal Note

issue-note-create

Post an internal note on an issue. It is not visible to the requester.

Reply to Issue

issue-reply

Send a customer-facing reply on an issue, visible to the requester. Use Post Internal Note for a private one.

Search Issues

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.

Snooze Issue

issue-snooze

Snooze an issue until a date and time.

List Issue Statuses

issue-status-list

List the organization's issue statuses, including custom ones. A status `slug` is a valid `state` for Update Issue.

List Issue Threads

issue-thread-list

List an issue's threads. A thread's `id` is what Post Internal Note takes as its internal thread.

Update Issue

issue-update

Change an issue's title, state, assignee, team, account, requester, tags or custom fields. Only the fields you set change.

Get Organization

me-get

Return the organization and the user the API token belongs to. Handy for confirming a token and region.

List Issue Messages

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.

Create Tag

tag-create

Create a tag for issues, accounts or articles.

List Tags

tag-list

List every tag, for issues, accounts and articles.

Update Tag

tag-update

Rename a tag or change its color.

Get Team

team-get

Fetch one team by ID, with its members, assignment method and schedule.

List Teams

team-list

List the organization's teams with their members and how each assigns issues.

Get User

user-get

Fetch one user by ID.

List Users

user-list

List the organization's users (support agents). Deactivated users are left out unless asked for.

Search Users by Email

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>"
      }
    }
  ]
}

Here are some of the things you can do

  • Create Account

    perform
    account-create
  • Get Account

    read
    account-get
  • List Accounts

    search
    account-list
  • Search Accounts

    search
    account-search
  • Update Account

    perform
    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.

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: "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);
Install the CLI
npm install -g @w6w/cli
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.

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

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).

Request MCP access

Health checks

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

service

Pylon platform status

status.usepylon.com (incident.io, Statuspage v2 shape). The `API` component decides; every other component is detail only.

dependency

API reachability

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.

quota

Quota headroom