Manage Wistia media and folders, read captions, and pull video and account stats.
Wistia ships in the w6w first-party pack. It declares 22 actions, 1 health check, and the host runs its code in a sandbox that never sees the credential.
io.w6w.wistiaWistia hosts and analyzes marketing video. This app lets a workflow list, rename, tag, move and delete media; import a video from a URL and poll the background job that processes it; and create, update and delete folders and read their subfolders.
It also reads what happens after publishing: per-video and account-wide stats (loads, plays, play rate, hours watched, engagement), caption tracks and transcripts, tags, and the account’s plan and usage, so a workflow can react to a video that is performing, or stop uploading when the plan is full.
Built on Wistia’s current /modern API with a single API token. Folders are what Wistia used to call projects.
Three routes to the same 22 actions. The Workflow tab is generated from Wistia'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-usage-get Plan, upload eligibility and usage against limits (media, storage, seats). Usage details are visible only to account owners and managers; other users get limits: null.
background-job-get Poll an asynchronous job started by Import Media from URL or Move Media: queued, started, finished or failed.
caption-get Fetch a media's captions in one language as JSON, with the full transcript text and optionally time-coded or speaker-turn segments. SRT, VTT and TXT downloads are not covered.
folder-list List folders (previously called projects). Personal My Library folders are not included.
media-delete Delete a media. It moves to the account's Recently Deleted area and can be restored there until the account's restore window ends, after which it is purged.
media-import-url Import a media file from a publicly accessible URL. Asynchronous: returns a background job to poll with Get Background Job, not the media itself.
media-list List the media in the account, optionally filtered by folder, name, type, tags or hashed IDs.
media-move Move up to 100 media to a folder (and optional subfolder). Asynchronous: returns a background job to poll with Get Background Job. Wistia allows 10 of these per 5 minutes.
media-stats-get Detailed stats for one video: loads, plays, play rate, hours watched, engagement, visitors and call-to-action actions. Needs a token with the Read detailed stats permission.
media-stats-summary-get Aggregated tracking stats for a video embedded on your site: page loads, visitors, play click rate, plays and average percent watched. Needs only the media read permission.
media-update Rename a media, change its description, replace its tags or swap its still image.
stats-account-by-date Account-wide loads, plays and hours watched per day, inclusive of both dates. Defaults to yesterday and today. Needs the Read detailed stats permission.
stats-account-get Account-wide totals: loads, plays and hours watched. Needs the Read detailed stats permission.
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 Wistia's real ids.
{
"manifestVersion": "2",
"name": "wistia-example",
"steps": [
{
"id": "background-job-get",
"uses": {
"app": "io.w6w.wistia",
"action": "background-job-get",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"jobId": "<jobId>"
}
}
]
}background-job-get account-get account-usage-get caption-get caption-list +17 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 Wistia, 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 Wistia. 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: "background-job-get",
payload: {
jobId: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value); npm install -g @w6w/cli w6w run conn_YOUR_CONNECTION_ID --action background-job-get --payload '{"jobId":"<value>"}' Give an AI agent Wistia — without giving it Wistia'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.wistia#background-job-get",
"input": {
"jobId": "<jobId>"
}
}
}
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 Wistia 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.
Wistia'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. Wistia itself is MIT, and the runtime that executes it is source-available (FSL).
Wistia declares its own checks, so its health is a property of the app rather than something the host guesses at.
Component status from status.wistia.com (Instatus). INFORMATIONAL: no component is named API, so App, Uploads, Encoding and Stats stand in for it.