Integrations / WooCommerce

WooCommerce integration that holds up under real traffic

WooCommerce is the most-installed ecommerce platform in the world by footprint, but every WooCommerce store is a custom build. The integration that works for one brand often does not work for the next, because the hosting, the plugins, and the order data model are all different.^[7]

REST v3

API surface stable since 2017

HPOS

Modern order storage, replacing post-meta

Action Scheduler

Reliable async queue used for webhook delivery

Hourly

Reconciliation cadence we run by default

TL;DR

We connect through the WooCommerce REST API v3 with consumer keys and a per-store webhook for orders, refunds, and inventory.
Most reliability problems on WooCommerce are not API problems. They are WordPress cron and host PHP-process problems.
We require High-Performance Order Storage (HPOS) on stores above moderate volume. Without it, large catalogs and order tables crawl.
Tracking back is posted as order meta plus optional Shipment Tracking plugin entries, so customer emails fire correctly.

Section 01

The WooCommerce REST API in plain English

The REST API is the only supported integration surface. It is namespaced under /wp-json/wc/v3 and authenticated with consumer key and consumer secret pairs that the admin generates from the store's user settings.^[1] No OAuth dance, no scopes, just keys.

The minimum subset of the v3 REST API a 3PL integration needs.

Endpoint	Method	Use it for
/orders	GET	Pull orders by status, date, customer
/orders/{id}	PUT	Set status, add line note, attach meta
/products	GET	List products, paginated
/products/{id}	PUT	Update price, stock_quantity, manage_stock
/refunds	GET	Pull refunds for accounting
/customers	GET	Customer record for order edits
/webhooks	POST	Subscribe to events

Section 02

Plugin or custom code, which to use

Two valid integration shapes exist for WooCommerce. We use both and pick based on the brand's hosting and operational posture.

Three integration patterns and when we use each.

Approach	How it works	When to pick it
External REST integration	We hold credentials, call the API from our infrastructure	Default for most brands; no plugin to maintain
3PL companion plugin	Custom WordPress plugin runs inside the store, talks to our API outbound	Stores with strict outbound firewall, or with custom order data the REST API cannot reach
Hybrid	Plugin handles webhooks and rate-limit safe writes; external pulls catalog and runs reconciliation	Largest stores and stores with bundle plugins

“The right answer is rarely "always plugin" or "never plugin". The right answer depends on whether the host can reliably make outbound network calls, which is not always a yes on shared hosting.”

Section 03

The hosting issues that break WooCommerce integrations

WooCommerce is a WordPress plugin. Its reliability inherits from WordPress itself, and WordPress runs on whatever PHP and database setup the host gives it. Most "WooCommerce integration is flaky" complaints we see come back to one of these four problems.

1. WordPress cron

Default WordPress cron only runs when a visitor hits the site. On a low traffic store at 3 AM, a webhook that was queued for retry can sit there for hours.^[4] The fix is a real system cron hitting wp-cron.php every minute, and disabling default WP cron in wp-config.php. We require this configuration before going live.

2. PHP process death

On shared hosting with max_execution_time of 30 seconds, a long export or large bulk update can cut off mid-run. Action Scheduler exists specifically to break long jobs into chunks.^[3] If a host kills cron jobs aggressively, Action Scheduler queues stall.

3. Object cache lies

Many managed WordPress hosts add an aggressive object cache. After an admin edits stock, the next API read may return the cached value for several seconds.^[8] The fix is to bypass the cache for the integration's API calls or to set cache TTL low for specific resources.

4. HPOS not enabled

Without High-Performance Order Storage, orders are stored as posts and postmeta, the same tables WordPress uses for blog posts. At scale, this is slow.^[5] Stores above 50,000 lifetime orders that do not enable HPOS can see API queries take 5 to 10 seconds. We strongly recommend HPOS on day one.

Section 04

The sync model

Trigger
Webhook fires from WooCommerce
Order created, order updated, order refunded. Payload includes the order ID and a signature header for verification.
Verify
HMAC check
We verify the X-WC-Webhook-Signature header before trusting the payload.
Fetch canonical
Re-read by ID
Webhook payload may be a partial. We fetch the order through the REST API to get the latest state.
Reconcile
Hourly diff
Pull every order changed in the last 90 minutes, compare to WMS, replay any miss.
Write back
Tracking and status
POST tracking number to the order as meta plus, if installed, the Shipment Tracking plugin entry.

Tracking notification

WooCommerce by itself does not send a tracking email when an order ships. The order email fires when status changes to "completed".^[2] For brands that want a richer email, we integrate with the official Shipment Tracking extension or with the brand's preferred email plugin.^[6] The integration writes the same tracking value into both surfaces.

Section 05

Going live without a hot weekend

The cutover process for WooCommerce is the same for every brand. The variation is in pre-cutover prep, which is where most of the time goes.

Confirm hosting can run real cron and supports outbound HTTP. We send a synthetic order to verify webhook delivery end to end.
Generate REST API consumer keys with read/write scope. Restrict by IP if the host supports it.
Enable HPOS on stores above moderate volume. Run the migration on a copy first if the catalog has custom postmeta on orders.
Audit installed plugins. Bundle plugins, subscriptions, and gift cards each have their own contract for line items.
Seed the catalog and inventory. Reconcile a sample of variants by hand before pushing the rest.
Cutover during a low-traffic window. Old fulfillment flow remains active in parallel for the first 48 hours.

Section 06

The plugin ecosystem and the integrations that matter

WooCommerce's strength is also its hardest part to support. Any number of plugins can write to orders, products, and inventory. The integration question is not "do plugins exist" but "which plugins write to the fulfillment-relevant fields and how do we coexist with them".

The plugin families we audit during onboarding, and how each interacts with the integration.

Plugin family	What it touches	Integration impact
Subscriptions	Recurring orders, renewals	Renewal orders fire orders/create like normal; we treat them identically
Bookings	Time-slot reservations, fulfilled physically or digitally	Often non-fulfillable; we filter via product type
Bundles and composite products	Parent SKU rolls up child SKUs	Requires a bundle definition contract before go-live
Shipping table rate	Per-zone, per-class shipping rules	Read-only for us; we honor what the plugin sets
Multi-currency	Per-locale presentment	Order arrives in store currency; we record presentment as metadata
Stock manager add-ons	Bulk inventory edits, low-stock notifications	Conflicts with our writes if not coordinated; we audit before go-live
Order export/import tools	CSV writes to orders	We refuse import-driven order ingest by default; surface in audit
B2B and wholesale	Customer-group pricing, NET terms	Treated like DTC for fulfillment, separate cutoff if requested

WooCommerce Subscriptions specifically

Subscriptions creates renewal orders on a schedule and fires orders/create when the renewal pays. The integration treats renewals the same as initial orders for fulfillment purposes.^[9] What changes is forecasting: renewal volume is more predictable than initial-order volume, so we expose a daily renewal forecast in the brand admin to help with labor scheduling.

Section 07

Authentication, security, and credential rotation

WooCommerce REST authentication is intentionally simple. Two valid options: consumer key and consumer secret pairs generated in the WooCommerce admin, or WordPress application passwords scoped to a system user.^[10]

Why we prefer application passwords

Consumer key pairs are tied to a WooCommerce REST user, but the permissions surface is coarse: read or write at the entire WooCommerce level. Application passwords let us scope to a specific WordPress user account and rotate independently of the WooCommerce REST user. We create a dedicated "warpspeed-integration" user with the minimum role needed and attach an application password to it. Rotating the password is a one-step admin operation that does not invalidate other integrations.

Webhook signature verification

WooCommerce signs webhook payloads with a secret defined at subscription time. Verification has the same trap as Shopify: framework auto-parsing of the body breaks the HMAC. The fix is the same; capture the raw body buffer at the edge, verify, then deserialize. WooCommerce additionally sends a delivery ID header that we use to deduplicate retries.^[2]

IP restriction and HTTPS

We restrict the integration's outbound traffic to known WooCommerce endpoints (per-store hostname allowlist) and require HTTPS on the store. Stores still serving WooCommerce over plain HTTP, which still happens on older self-hosted setups, are blocked from going live until they switch. The rare exception is a store running behind a corporate VPN with TLS terminated upstream, where we work with the brand to confirm the path.

Section 08

Database performance, the hidden ceiling

Most WooCommerce performance problems are database problems. WordPress's schema is general-purpose; the postmeta table where pre-HPOS orders live is queried with serialized PHP arrays as values, which the database cannot index meaningfully. Above 50,000 lifetime orders, query time grows roughly linearly with order history.^[5]

HPOS as the fix

High-Performance Order Storage moves orders to dedicated tables with real indexes. The migration is one-time and can take hours on a large store, so we run it during a maintenance window with the brand. Stores on managed hosts (WP Engine, Pantheon, Kinsta) often have host-supplied tooling for the migration that runs faster than the in-product tool.

Index hygiene and queries we own

Our integration queries are scoped to specific endpoints (orders by status, orders by date range, products by ID). We do not run ad-hoc reports against the database directly; everything goes through the REST API or staged exports. This avoids accidental table-locking queries during peak. The brand sees our query rate in the host's slow-query log if they look, and it has never been the cause of a slowdown.

“The fastest WooCommerce stores run boring infrastructure: HPOS enabled, real cron, opcache on, object cache scoped, MySQL tuned for the workload. Nothing exotic. Every shortcut in this stack costs you reliability later.”

Cron, jobs, and Action Scheduler

Action Scheduler is the queueing system WooCommerce ships with. It is what actually runs background work like webhook delivery, scheduled emails, subscription renewals, and our own integration jobs.^[3] The reliability of any WooCommerce integration depends on Action Scheduler being healthy. We monitor its queue depth, in-progress count, and failed count, and surface those alongside our own metrics in the brand admin.

When the queue grows unbounded, the cause is usually one of three things: real cron is not running often enough, the worker is killed by PHP timeout before completing the action, or a single failing action is blocking the queue. Each has a different remediation. We treat a stuck Action Scheduler as a paging-level event because most of the brand-facing functionality depends on it.^[11]

Section 09

Headless and decoupled WooCommerce

An increasing number of WooCommerce stores run with a decoupled front end: a Next.js, Remix, or static site that hits the WooCommerce REST API for product and cart data and sends checkouts back through. From the integration's perspective, this changes nothing.

The order shape stays the same

Whether the customer checked out through a Storefront theme or a custom React front end, the resulting order is the same WooCommerce order. The webhook fires the same way, the REST endpoint returns the same shape, the fulfillment write goes to the same place. We integrate the same way regardless of front-end choice.

What is harder for headless stores

The thing decoupled stores struggle with more than coupled stores is email. WordPress emails fire from PHP on the back end; if the back end is not actively serving customer traffic, those emails can sit in a queue waiting for a request to flush them. We recommend pairing decoupled stores with a real transactional email service and triggering emails through that path rather than relying on WordPress's default mail handling.

Section 10

Tracking back, returns, and customer communication

The tracking and returns surfaces in WooCommerce are less prescriptive than Shopify's. Brands build a workflow that fits their plugin stack, and the integration meets them there.

Tracking write strategies

We support three tracking write patterns. The order-meta-only pattern writes carrier and tracking number to order metadata; this is the simplest and works without any extra plugins, but does not trigger emails. The Shipment Tracking plugin pattern uses the official extension's REST endpoints to register tracking entries; this populates the order email and the order page on the storefront.^[6] The custom-plugin pattern is for brands that have built their own tracking UI and want us to write into their custom post-type. We support all three; the brand picks at onboarding.

Returns workflow

WooCommerce by itself does not have a returns flow. Brands typically use one of three plugins (or a third-party returns service like Loop or Aftership Returns) and the integration writes return acknowledgments where they expect. For brands without a returns plugin, we operate returns out of the brand admin in our own console, and the WooCommerce order's status is updated to "refunded" when the refund actually fires. The brand decides whether the refund is on receipt or on grade.

Email plugins and inbox placement

WooCommerce's default emails are functional but plain. Most brands swap them for a transactional email service (Postmark, SendGrid, Klaviyo) for both deliverability and design. The integration's tracking writes need to reach whichever service the brand uses; we do this by writing the tracking field to the canonical WooCommerce order, and the email service picks it up through its own plugin or webhook. This keeps us out of the email business while making sure the brand's customer comms stay accurate.

Section 11

Hosting choices that make the integration easier

We do not require a specific host, but the hosting choice has more impact on integration reliability than any other infrastructure decision the brand makes. The reasons trace back to the cron, PHP, and database issues we covered earlier.

The host categories we see

Managed WordPress hosts (WP Engine, Kinsta, Pantheon) handle most of the infrastructure heavy lifting and ship with reasonable defaults. Generic VPS hosts (DigitalOcean, Linode, Hetzner) give the brand control and the option to tune for their specific traffic shape, but require more operational discipline. Shared hosts (smaller providers) are workable for low-volume stores but break down above moderate traffic. Brands that outgrow shared hosting usually move to a managed WordPress host before moving to a VPS.

A short configuration checklist

Before go-live we verify five host settings. PHP 8.1 or higher with opcache enabled. MySQL or MariaDB version supported by the WooCommerce version. A real cron job hitting wp-cron.php every minute. Object cache configured (Redis or Memcached) and scoped to skip our integration's API keys. Outbound HTTP working without firewall blocks. These five checks catch most of the issues we see in the first 30 days.

The verification we run is automated. We push a small synthetic payload through every layer (cron, queue, REST API write, webhook delivery) and the result lands in the brand admin before launch. Brands almost always fix something at this stage that they did not know was wrong.

Talk to us

We have onboarded WooCommerce stores from every host

Send us your hosting details and a list of installed plugins, and we will tell you exactly what your cutover will involve.

Sources

[src-1]WooCommerce REST API v3— WooCommerce
[src-2]WooCommerce webhooks— WooCommerce
[src-3]Action Scheduler— WooCommerce
[src-4]WordPress cron, alternative cron— WordPress.org
[src-5]WooCommerce HPOS, custom order tables— WooCommerce
[src-6]WooCommerce shipment tracking— WooCommerce
[src-7]BuiltWith, ecommerce platform usage— BuiltWith
[src-8]WooCommerce stock-management settings— WooCommerce
[src-9]WooCommerce Subscriptions extension— WooCommerce
[src-10]WordPress REST authentication, application passwords— WordPress.org
[src-11]WP-Cron alternatives and crontab— WordPress.org Codex