First-party app
Pendo

Pendo

Send Pendo track events, read visitor/account/page/feature/guide data, set metadata fields, run aggregation queries, and process GDPR/CCPA deletion requests.

stable Analytics & BI

About

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

App id
io.w6w.pendo
Version
0.1.0
Author
w6w
Licence
MIT
Categories
Analytics & BI

Overview

Pendo is a product analytics and in-app guide platform, and this app covers the parts of its REST API that a workflow actually reaches for: sending track events, reading back visitor, account, page, feature and guide data, setting or reading a metadata field on a visitor or account, running Pendo’s own Aggregation pipeline language for analytics queries, pulling a saved report’s results, and filing a GDPR/CCPA bulk-deletion request.

The API is really two credentials on five regional deployments. The main Integration Key reads and (optionally) writes everything under /api/v1; a separate Track Event Shared Secret — a DIFFERENT value from the integration key — is required for the ingest endpoint on the data.*.pendo.io hosts. Getting them mixed up is the most common way a Pendo connection looks broken when it isn’t, so this app keeps them as two explicit fields and injects the right one per host.

Build with Pendo

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

Bulk Delete Visitors or Accounts

bulk-delete

File a GDPR/CCPA bulk-deletion request for a set of visitor or account ids. IRREVERSIBLE and asynchronous — Pendo returns a job id, not a confirmation the data is gone; poll `GET /api/v1/bulkdelete/:id` in the Pendo UI or API to check status.

Get Account

get-account

Look up a single account by id — metadata and auto-collected fields.

Get Metadata Value

get-metadata-value

Read the value of one metadata field on a single visitor or account.

Get Visitor

get-visitor

Look up a single visitor by id — metadata, account membership, first/last seen.

List Features

list-features

Return every Feature definition, or a specific set by id.

List Guides

list-guides

Return every Guide definition, or a specific set by id.

List Pages

list-pages

Return every Page definition, or a specific set by id.

Get Report Results

report-results

Return a saved report's rows as JSON. Paths, Funnels, Retention, and Data Explorer reports are NOT supported by this endpoint — Pendo publishes no API for those.

Run Aggregation

run-aggregation

Run a Pendo Aggregation pipeline — the query language behind Pendo's own reports. NOT a bulk export tool: a single call is capped at a 5-minute runtime or 4 GB of output.

Set Metadata Value

set-metadata-value

Set the value of one metadata field on a single visitor or account. A new `custom` field is created automatically if the name doesn't exist yet; every other group needs the field to already exist in Data Mappings.

Track Event

track-event

Record a user action as a Pendo track event. Needs the Track Event Shared Secret — a DIFFERENT credential from the Integration Key used by every other action here. A timestamp older than now is silently deferred to Pendo's daily/weekly reprocessing rather than the regular hourly job, and one over 7 days old may not be processed at all.

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

{
  "manifestVersion": "2",
  "name": "pendo-example",
  "steps": [
    {
      "id": "get-account",
      "uses": {
        "app": "io.w6w.pendo",
        "action": "get-account",
        "connection": "conn_YOUR_CONNECTION_ID"
      },
      "with": {
        "accountId": "<accountId>"
      }
    }
  ]
}

Here are some of the things you can do

  • Get Account

    read
    get-account
  • Get Metadata Value

    read
    get-metadata-value
  • Get Visitor

    read
    get-visitor
  • List Features

    read
    list-features
  • List Guides

    read
    list-guides

+6 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 Pendo, 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 Pendo. 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: "get-account",
  payload: {
    accountId: "<value>",
  },
});

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

Give an AI agent Pendo — without giving it Pendo'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.pendo#get-account",
    "input": {
      "accountId": "<accountId>"
    }
  }
}

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

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

Request MCP access

Health checks

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

service

Pendo service status

Pendo's per-region status page, narrowed to the API, ingest, and query components this app's actions depend on.

quota

Request headroom