Fulfill orders and buy shipping labels across every carrier connected to a ShipStation account.
ShipStation ships in the w6w first-party pack. It declares 18 actions, 3 health checks, and the host runs its code in a sandbox that never sees the credential.
io.w6w.shipstationShipStation creates shipments, gets carrier rates, buys and voids labels, and manages warehouses and carrier accounts across every carrier connected to a ShipStation account, built entirely against ShipStation’s current V2 API rather than the deprecated V1 surface. Getting a rate and creating a shipment are kept conceptually distinct from buying a label — a label purchase is the one step that actually spends money and issues a tracking number, and it can be built from a rate, a shipment, or details supplied directly.
A shipment can be listed, read, updated before a label is bought, and cancelled; purchased labels can be listed, read and voided for a refund where the carrier allows it. Warehouses and reusable shipment tags can be created and listed, and every carrier account connected to the account can be read individually or as a whole.
Health reporting follows ShipStation’s own V2-specific status component rather than the page as a whole, and separately reports when a connection has no carrier accounts to ship with at all — a state that otherwise looks like an ordinary validation error rather than what it actually is. Sales orders, batches, manifests and automatic rate-shopping rules are left out, either because they sit behind a higher plan or because they belong to ShipStation’s own dashboard rather than a workflow step.
Three routes to the same 18 actions. The Workflow tab is generated from ShipStation'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.
carrier-list List every carrier account connected to this ShipStation account.
label-create Purchase a shipping label — from a rate id, a shipment id, or full inline shipment details. Called a "shipment" in the ShipStation UI and its legacy V1 API. THIS SPENDS MONEY on a production API key.
label-list List purchased labels with optional filters. Paged, most-recently-created first.
label-void Void a purchased label. Cannot be undone — a new label must be purchased afterward if the shipment still needs to go out.
rate-get Get carrier price quotes for a shipment you describe inline. NOTE: ShipStation stores this as a real shipment record as a side effect — see `shipmentId` in the output.
rate-list-for-shipment Retrieve rates already calculated for an existing shipment, without requesting new ones (no side effect, unlike `rate-get`).
shipment-cancel Cancel a shipment record. If a label was already purchased for it, void that label first — ShipStation refuses to cancel a shipment with a live label.
shipment-create Describe what you're shipping — addresses, package(s), carrier and service. Called an "order" in the ShipStation UI and its legacy V1 API. Creates no label and buys nothing.
shipment-get Look up one shipment by its ShipStation `shipment_id` or by your own `externalShipmentId`.
shipment-list List shipments with optional filters. Paged, most-recently-modified first.
shipment-tag-add Tag a shipment so it can be filtered later. Creates the tag if it doesn't already exist.
shipment-update Replace a shipment's details before a label is purchased for it. Treat this as a FULL replace — fetch the current shipment first and carry its fields forward.
tag-create Create a reusable shipment tag ahead of time. A tag is just its name, so re-creating an existing one is expected to be harmless (not separately verified against a live duplicate).
warehouse-create Create a shipping warehouse. The FIRST warehouse ever created on an account automatically becomes the default, with no way to opt out of that.
warehouse-list List every shipping warehouse (ship-from/return address) set up on this account.
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 ShipStation's real ids.
{
"manifestVersion": "2",
"name": "shipstation-example",
"steps": [
{
"id": "carrier-get",
"uses": {
"app": "io.w6w.shipstation",
"action": "carrier-get",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"carrierId": "<carrierId>"
}
}
]
}carrier-get carrier-list label-create label-get label-list +13 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 ShipStation, 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 ShipStation. 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: "carrier-get",
payload: {
carrierId: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value); npm install -g @w6w/cli w6w run conn_YOUR_CONNECTION_ID --action carrier-get --payload '{"carrierId":"<value>"}' Give an AI agent ShipStation — without giving it ShipStation'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.shipstation#carrier-get",
"input": {
"carrierId": "<carrierId>"
}
}
}
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 ShipStation 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.
ShipStation'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. ShipStation itself is MIT, and the runtime that executes it is source-available (FSL).
ShipStation declares its own checks, so its health is a property of the app rather than something the host guesses at.
The `Companion API V2` component on ShipStation's status page — the only component this app calls. Carrier outages (UPS, FedEx, USPS/Stamps.com, ...) are reported by name but do not count toward this verdict, because a dead carrier leaves the API itself fine.
Whether this connection has at least one carrier account set up. A valid API key with no connected carrier answers every rate/label request with a validation error, not an auth error, so this check exists to surface that before a workflow run does.