How to Set Up ShipEngine Shipping on WooCommerce

TL;DR

What you need:

• A ShipEngine (now ShipStation API) account with an API key. Your old ShipEngine key still authenticates after the rebrand. Tiers and prices change, so check Auctane’s current ShipEngine pricing.
• The free ShipEngine shipping plugin from WordPress.org. PRO adds labels, tracking, box presets, and bulk fulfillment.

The setup, in six steps:

1. Confirm you have the ShipEngine API (not the ShipStation app), and grab your API key.
2. Install the free ShipEngine shipping plugin and confirm the CLI namespace with wp help | grep shipping.
3. Discover the credential keys with settings list, then set the key and origin.
4. Audit product weights and dimensions, add your boxes, and enable your services.
5. Run validate and a real rates quote to confirm the API is reachable.
6. Attach the plugin to your shipping zones and turn on live rates.

Rather not run any of it yourself? Install the skill once and an assistant like Claude Code handles the whole sequence:

$ npx skills add https://github.com/1TeamSoftware/skills --skill 1teamsoftware-wc-shipping

ShipEngine vs ShipStation: which one do you have?

This trips up almost everyone, so it is worth a minute. Auctane sells two things that sound alike, and only one of them belongs at your checkout.

• ShipStation is the app: a hosted dashboard where you import orders from your sales channels, batch them, buy labels, and push tracking back. There is an official ShipStation integration for WooCommerce, and it does that job. It exports your orders into the dashboard after checkout. It does not quote a rate to your buyer.
• ShipEngine is the API behind that app: a developer-facing interface that returns rates, validates addresses, buys labels, and tracks shipments over HTTP. On 2025-02-28 Auctane renamed it ShipStation API. Same endpoints, same keys, same carriers. There has never been an official WooCommerce plugin for it, because an API is meant to be wired into something.

So if your goal is a real shipping price at the WooCommerce checkout, neither Auctane product gets you there alone. The ShipStation app imports orders too late, and the ShipEngine API has no front end. What you need is something WooCommerce-native that calls the ShipEngine API the moment a buyer enters an address. That is this plugin.

One row in that table needs a plain-English note. Multivendor origin only matters if you run a marketplace where different sellers ship from their own addresses. Plugins like Dokan, WCFM, and WCMP turn one WooCommerce site into that kind of marketplace, and this plugin can quote each vendor’s parcel from their own location. Sell your own products out of a single warehouse? Ignore that row entirely.

For the full feature-by-feature breakdown, see the ShipEngine Shipping PRO product page.

Before you start

Live rates depend on two prerequisites, and both are external to WooCommerce: an authenticated ShipEngine account with an API key, and the free plugin that consumes it. Provision those two and everything after is fast.

A ShipEngine account with an API key. The plugin pulls rates and buys labels through this API, so the account needs to be active and provisioned for the carriers you ship with. Carrier availability is set on Auctane’s side, not in the plugin. Your pre-rebrand ShipEngine key still works, and nothing in your code or settings has to change because of the name swap. If you are choosing a tier, check Auctane’s current ShipEngine pricing.

The free plugin. Install the free ShipEngine shipping plugin from WordPress.org. It covers the API connection and live rates. Labels, tracking, box presets, and bulk fulfillment live in PRO.

Set it up from the command line

If you already drive ShipEngine over HTTP, you will feel at home here: the plugin mirrors its entire setup into a WP-CLI namespace, so you script the configuration instead of clicking through admin screens. Every command maps to a setting or an API call you could otherwise make by hand. It is the pillar guide, configure WooCommerce shipping with AI and WP-CLI, applied to ShipEngine specifically.

The commands live under a per-plugin namespace, which is the plugin slug with -pro removed. For ShipEngine that is wc-shipengine-shipping, the same for both the free and PRO editions. Confirm it on your site before scripting:

$ wp help | grep shipping

Use whatever namespace it prints back. Every example below uses wc-shipengine-shipping.

See where you stand

Start with these two. Neither mutates state; both are pure GET-style reads that echo back the current config and surface what is broken, leaving every setting untouched.

$ wp wc-shipengine-shipping status
$ wp wc-shipengine-shipping validate
validator              status  message
License Status         PASS    License is activated
Ship From              PASS    From Address configured
Product Dimensions     WARN    Only 27% of products have valid dimensions
Cart Rates             PASS    Rates working: 4/4 routes, 15 rate(s) total
Shipping Services      PASS    7 service(s) available
Shipping Zones         PASS    Using global shipping rates
Sandbox Mode           INFO    Sandbox mode is active

status prints a snapshot of your config: version, carrier, the sandbox and debug flags, whether live rates are on, the origin, and how many method instances exist. It carries no “is the API reachable” field, because only a rates quote proves connectivity. validate runs the configuration through each assertion and stamps the result with a status of PASS, FAIL, WARN, INFO, or PENDING. Treat its exit status the way you would any other API health probe: a single FAIL flips the process exit code to non-zero, which is precisely the signal a deploy pipeline reads to halt a release.

Discover the credential keys, then set them

ShipEngine’s credential keys differ from carrier to carrier across the line, so read the exact setting key names off your install rather than guessing them. List the settings first. Secrets come back as [REDACTED], so this is safe to run anywhere:

$ wp wc-shipengine-shipping settings list

Find the credential key in the output, then set it along with your origin address. Replace <apiKeyName> with the exact key name settings list showed you:

$ wp wc-shipengine-shipping settings set <apiKeyName> "your_shipengine_api_key"
$ wp wc-shipengine-shipping settings set enableLiveShippingRates yes
$ wp wc-shipengine-shipping settings set origin '{"name":"My Store","address":"123 Main St","city":"San Francisco","state":"CA","postcode":"94105","country":"US"}'

One rule saves you a support ticket: never hard-code a credential key name for a carrier you have not inspected. Run settings list and read the real one. The origin object will not satisfy the API without address, city, country, and postcode populated. For US and Canada destinations, include state in that JSON as well; ShipEngine returns tighter rates when it has the subdivision to work with.

Audit your products

The ShipEngine API prices a parcel from its weight and dimensions, so missing values are missing inputs. A product with no weight is dropped from the request payload, and an empty payload is one of the most common reasons the API returns an empty rate set:

$ wp wc-shipengine-shipping products audit --detailed --format=json --limit=0

The per-product lists (missing_weight_products, missing_dimensions_products, suspicious_data_products) only show up with --format=json. In table mode, --detailed gives you the same summary as plain audit. Pass --limit=0 so a big catalog isn’t capped at 500. Virtual and downloadable products drop out automatically, and variations inherit weight and dimensions from the parent.

Find your services and enable them

List the carrier services your ShipEngine account exposes, then enable only the ones you actually ship with.

$ wp wc-shipengine-shipping services --format=json
$ wp wc-shipengine-shipping settings set services '{"usps_ground_advantage":{"enabled":true,"name":"USPS Ground Advantage"}}'

services lists the real service IDs your account exposes, each with its enabled status. Pull your service IDs from that response, not from features; the features command is a read-only capability inventory and is not what you write back. Always pass valid IDs from services into settings set services. Don’t invent IDs; they won’t match and the rate won’t appear. Because ShipEngine fronts many carriers under one key, the available IDs depend on which carriers your Auctane account has provisioned.

Quote a rate to prove it works

Run a real quote against your credentials. This is what confirms the ShipEngine API is reachable and handing back prices.

$ wp wc-shipengine-shipping rates quote --products="123" --destination="500 5th Ave, New York, NY 10001, US"

rates quote spins up a temporary order, asks the ShipEngine API for a live quote, then deletes the order. The smallest --destination the API will accept is a ZIP or postcode paired with a country; feed it a complete street address and the returned rates get more precise. A quote that returns rates is the only real proof the API is reachable, and there’s no separate test-connection command, by design. One gotcha when you script it: the command prints a human-readable log line before the JSON, so parse the array from the first [ to the matching ] instead of leaning on 2>/dev/null.

A note on --format while you’re here. status, validate, features, services, zones, and rates accept the full table|json|csv|yaml|count range. The products subcommands, boxes, track, and settings list stick to table|json, and anything outside that errors out instead of guessing what you meant.

For every command, flag, and output field, see the full WP-CLI command reference.

The developer-friendly path: hand it to an AI agent

If you came here from the API side, this part will feel natural. You already talk to ShipEngine in code; here you talk to the plugin in plain English. Install the skill once and an assistant like Claude Code drives every command above for you. It ships with playbooks for the jobs that actually come up, and it picks the right one for what you asked, so you describe the outcome instead of remembering which subcommand to run. There’s no hidden layer here. It runs the same CLI you would, and it stops to ask for your API key instead of making one up.

$ npx skills add https://github.com/1TeamSoftware/skills --skill 1teamsoftware-wc-shipping

Once it’s installed, just describe what you want with real constraints. These are the kinds of multi-step requests it’s built for:

• “Set up ShipEngine from scratch. Here is my API key. We ship from 215 Clayton St, San Francisco 94117. Before you turn on live rates, show me which credential field this carrier actually uses, audit my catalog for missing weight or dimensions, recommend a starter box set from what I actually sell, and prove rates come back with a real quote. Ask me one question at a time.”
• “We rate-shop USPS and UPS through ShipEngine. List the real service IDs my account exposes, enable only those two carriers’ ground and priority services, disable the rest, and show me the enabled list when you’re done.”
• “Customers in some regions say no shipping options appear. Make the plugin active for both my US domestic zone and Rest of World, then show me the zone coverage table so I can confirm it’s attached where it needs to be.”
• “Our shipping is undercharging. Survey live ShipEngine rates for my three best sellers to a few US zones, add a 15% markup plus a flat $2 handling fee, show me the before and after, and apply it only after I confirm.”
• “Add a post-deploy check that fails the build if our shipping config has any FAIL-level problems, and make sure stderr noise doesn’t corrupt the JSON the check parses.”

Show live ShipEngine rates at checkout

This is the glue the raw API never ships, so it is worth spelling out. Two switches arm it: live rates enabled, and the plugin attached as a shipping method on the zone. From there the flow is a request-response loop on every address change. A buyer types a destination, the plugin packs the cart into your configured boxes, posts that parcel and destination to the ShipEngine API, and renders whatever carrier prices come back as checkout options, the very figures ShipEngine bills you when you later buy the label. Rates for some buyers but not others means a zone is missing the method, and the zones case below carries the command that repairs it.

A few settings tidy it up. Cap how many options appear so buyers aren’t staring at a dozen choices (maxShippingRates), rename services so they read clearly, and add a handling fee or percentage markup when the margins call for it. Rates render on both the classic checkout and the WooCommerce Blocks cart and checkout, and the whole thing is HPOS-aware. Run a marketplace like Dokan or WCFM? Rates can calculate from each vendor’s origin.

Common situations you’ll hit

The API is answering at checkout now. What follows are the field cases that surface once live traffic starts: missing payload data, oversized parcels, an unrouted zone, each with the call that fixes it.

Enable only the carriers you rate-shop

ShipEngine’s whole appeal is breadth: one key, dozens of carriers. That is also the trap. Leave everything on and your checkout turns into a wall of fifteen near-identical options, and conversion takes the hit. The fix is to find the real service IDs your account exposes and enable a tight set. You’d tell the agent something like “List the real service IDs ShipEngine exposes for my account, then enable only USPS Ground Advantage, USPS Priority, and UPS Ground, disable everything else including international, and show me the enabled list.”

$ wp wc-shipengine-shipping services --format=json
$ wp wc-shipengine-shipping settings set services '{"usps_ground_advantage":{"enabled":true,"name":"USPS Ground Advantage"},"usps_priority":{"enabled":true,"name":"USPS Priority"},"ups_ground":{"enabled":true,"name":"UPS Ground"}}'
$ wp wc-shipengine-shipping services

It reads the live IDs from services first, because the exact strings depend on which carriers Auctane has provisioned for you, and the international IDs differ from the domestic ones (usps_priority_international is not usps_priority). It writes a keyed object, not an array, then re-runs services to confirm the enabled flags. Ship cross-border and you enable both the domestic and international IDs. What lands at checkout is only the services you chose, a list short enough to convert.

Fix products missing weight or dimensions

The situation: a catalog that grew over years of imports, and rates quietly vanish because some products carry no weight. Send the ShipEngine API a weightless parcel and it hands back nothing, so the buyer sees no shipping option and stalls.

What you type: “Audit every physical product for missing weight and dimensions, give me the completeness percentage and the full list of what’s incomplete (don’t cap it, I have a big catalog), then research real specs from manufacturer sources, apply only high-confidence values to the parent and every variation in my store’s units, and list the rest for me to confirm by hand. Never make up a number.”

What runs:

$ wp wc-shipengine-shipping products audit --detailed --format=json --limit=0

The agent reads the missing_weight_products, missing_dimensions_products, and suspicious_data_products arrays, looks up the real specs, converts them into your woocommerce_weight_unit and dimension_unit, then writes them with wp wc product update across the parent and every variation. Only high-confidence numbers get applied. The low-confidence and not-found ones come back to you for sign-off. A value lands in the suspicious bucket once a weight climbs past about 70 lb (32 kg) or a single dimension runs beyond about 72 in (183 cm). It won’t fabricate a spec it can’t source, which is the whole point.

The result: completeness climbs, rates stop disappearing, and you’re left with a short list of genuine unknowns instead of a catalog-wide guessing game.

Recommend a box set from what you actually ship

The situation: rates look high because parcels are quoted in oversized boxes nobody matched to the real catalog. A small item priced as if it ships in a large box shows the buyer an inflated number, and that number is often the difference between a completed order and a closed tab.

What you type: “Analyze my last six months of orders and my catalog, recommend a box set that covers about 90% of what I ship, prefer USPS flat-rate boxes where they’d be cheaper for heavy items, show me the coverage table before applying anything, and keep my existing custom boxes.”

What runs:

$ wp wc-shipengine-shipping products stats --format=json
$ wp wc-shipengine-shipping products orders --since=2025-12-01 --format=json
$ wp wc-shipengine-shipping boxes presets --carrier=USPS --format=json
$ wp wc-shipengine-shipping products fit-box --length=12 --width=8 --height=6

products stats and products orders describe the real product shapes and the carts they ship in. products fit-box takes box dimensions (all three required) and reports coverage plus a sample of products that won’t fit; it rotates parcels for you. Here’s the catch: boxes presets output can’t be pasted into the boxes setting as-is. The agent reshapes each field first (rename name to boxName, add an enabled flag, drop carrier and maxweight), shows you a coverage table, and only then writes the merged set with settings set boxes. boxes itself is a PRO command; on a free install you write the boxes setting straight through the free settings set boxes.

The result: a box set sized to your actual catalog and order patterns, with coverage you can eyeball before you commit.

The “no rates at checkout” fix: shipping zones

The situation: rates work for some customers and not others. When the API itself is answering but checkout still goes blank, the routing layer is almost always the culprit, not the credential. The plugin only returns rates on the zones where it’s attached as a shipping method, so any zone it’s missing from shows the buyer nothing.

What you type: “rates quote works from the CLI but checkout shows nothing for some customers. Figure out which zone those addresses fall into, check whether the plugin is actually attached, and add it where it’s missing.”

What runs:

$ wp wc-shipengine-shipping zones
$ wp wc shipping_zone_method create --zone_id=2 --method_id=wc-shipengine-shipping --user=1

zones lists each zone alongside its plugin_active, instance_id, and method_id. Wherever plugin_active: no shows up, that’s a zone missing the method. The flag only bites under zone-based routing, where an unattached zone returns nothing for addresses that land in it; run global rates instead and the per-zone attachment is moot. Once the method is attached, you can layer per-zone overrides through --instance, for example a different box or service mix for international versus domestic, while your global defaults stay untouched. Every wp wc command needs --user=1.

The result: the plugin is attached to the zones that need it, and checkout returns rates.

A CI gate for agency and multi-store work

This one is for the developer audience ShipEngine attracts. If you provision stores from a pipeline, you want a broken shipping config to fail the build, not surface as a support ticket after launch. Ask the agent for “a post-deploy gate that fails the build if our shipping config has any FAIL-level problems (WARN is fine), and make sure stderr noise doesn’t corrupt the JSON the check parses” and you get a one-liner you can drop into any deploy script:

$ wp wc-shipengine-shipping validate --format=json 2>/dev/null \
  | jq -e 'all(.[]; .status != "FAIL")' >/dev/null \
  || { echo "Shipping config has failures"; wp wc-shipengine-shipping validate; exit 1; }

Because validate exits non-zero on any FAIL, it slots straight in. WARN doesn’t fail the build, only FAIL does. Pair it with scripted provisioning that sets the key, origin, and box set from a standard config file, and every store comes up identically. For locked-down managed-hosting fleets, the same values can be pre-seeded through wp-config.php constants so on-site admins never touch the credentials. The payoff: a misconfigured store blocks its own release instead of reaching customers.

Print labels and track shipments (PRO)

Once a license is active, the same CLI buys labels, merges them into print-ready PDFs, and pulls tracking. Daily fulfillment runs as one batch:

$ wp wc-shipengine-shipping labels purchase --orders=1240,1241,1242
$ wp wc-shipengine-shipping labels pdf --orders=1240,1241,1242 --output=/var/labels/2026-06-11.pdf
$ wp wc-shipengine-shipping track <shipment-id> --order=1240 --format=json

labels purchase creates the shipment if it’s missing and logs how many labels it bought (Order 1240: N label(s) purchased). It does not print the tracking number. Pull that from track or shipments get. labels pdf takes a mandatory --output path and refuses to overwrite, so it throws when that file is already there; key the filename on the date to sidestep the collision. track wants both the positional shipment ID and --order.

For hands-off fulfillment, wrap the first two in a nightly cron that collects the day’s processing orders, buys their labels in one batch, and merges them into a dated PDF for the morning print run. The PRO plugin also carries built-in automation settings for auto-updating tracking and pushing carrier orders, configurable through wp-config.php (see the automation reference). Labels, returns, tracking, box presets, and bulk fulfillment all live in ShipEngine Shipping PRO if you want the whole pipeline inside WooCommerce.

Works the same across every carrier

ShipEngine is one of eight carrier plugins on the same engine. The commands are identical everywhere. The only things that change are the namespace and a few setting keys.

A note for anyone weighing ShipEngine against ShipStation. They run on the same engine, so the real choice is API versus app. Take the ShipEngine API plugin if you want a Woo-native integration on your existing developer key. Pair it with the ShipStation v2 plugin only if you also run multi-channel fulfillment in the ShipStation dashboard. The current ShipStation plugin uses the carrier’s API v2, so its namespace is wc-shipstation-shipping-v2; confirm any namespace with wp help | grep shipping. Carrier pricing is never hard-coded in these plugins, which is why a live rates quote is always the source of truth. If you’re still choosing an aggregator, see ShipStation vs Shippo vs EasyPost.

Security

Nothing exotic here, just a few habits that keep a live key from leaking:

• Share your key with an agent only when you genuinely need to, and rotate it afterward if you want to be careful. The agent asks for keys; it never invents them.
• Keep the credential in a wp-config.php constant rather than the database. Those constants take precedence over the DB, are never written back to it, and can hide the credential field from the admin UI, which is how agencies lock down managed-hosting fleets.
• Secrets are redacted in output by default. settings list shows them as [REDACTED], and settings get keeps them masked unless you add --raw.
• Switch debug back off once you’ve finished diagnosing. Debug mode writes raw API requests and responses to the log, the last thing you want lingering in production.

Get live ShipEngine rates on your store

The ShipEngine API already returns rates. It just has nowhere to show them on WooCommerce, and this plugin gives it the front end. Install the free ShipEngine shipping plugin from WordPress.org, set your existing API key, and quote a real rate to confirm it works. When you’re ready for labels, tracking, multi-box packing, and bulk fulfillment inside WooCommerce, that’s all in ShipEngine Shipping PRO.

$ npx skills add https://github.com/1TeamSoftware/skills --skill 1teamsoftware-wc-shipping

1TeamSoftware builds and maintains the ShipEngine shipping plugin for WooCommerce and eight other carrier plugins, used by thousands of stores.