Skip to main content
Back to blog

WooCommerce Cart Recovery — the Same Playbook as Shopify, on an API Key

How Devotel Orbit's WooCommerce integration gives a self-hosted WordPress store the same abandoned-cart and order-lifecycle messaging as the Shopify route — a validated REST API key pair replaces the OAuth popup, and customers, orders, and products sync into the same contact rows.

Orbit Editorial Team

WooCommerce is the store platform that runs on your own hosting, which is exactly why commerce-messaging coverage tends to skip it: there is no app store to connect through and no central OAuth authority to redirect past. Devotel Orbit's WooCommerce integration closes that gap. The recovery playbook we published for Shopify — trigger on the cart event, delay, exit on self-completion, send the template — runs unchanged here; only the connect path differs. This post covers the parity setup, what actually lands in Orbit from a WooCommerce store, a worked recovery flow, how to measure it, and the compliance posture that stays in your hands.

Parity setup: an API key pair instead of the OAuth popup

Shopify connects with an OAuth redirect because Shopify hosts an OAuth authority. WooCommerce is self-hosted, so the correct analog is a REST API key pair — and the connect flow treats it with the same rigor as a password exchange.

The setup is three steps, and none of them involve an app review:

  1. Generate the key pair. In WordPress, go to WooCommerce → Settings → Advanced → REST API and create a key pair with read access (read/write if you plan to act on orders, not just read them). WooCommerce shows you a consumer key (ck_…) and consumer secret (cs_…) exactly once.
  2. Paste it into Orbit. In Orbit, go to Settings → Integrations → WooCommerce, and enter your store URL with the key pair. No redirect, no popup, no approval wait.
  3. Turn on the flows. Enable the post-purchase and abandoned-cart flows you want to run on new WooCommerce orders.

Connect is not a blind save. When you paste the credentials, Orbit probes the live store with a single GET /wp-json/wc/v3/orders?per_page=1 request over HTTP Basic — a one-record read that returns 200 for a valid key with any useful scope. The failure codes map to the corrective action, so the dialog can tell you what to fix instead of saying "failed":

Probe resultWhat the integration reportsWhat to fix
401/403 from the storeCredentials rejectedRegenerate the key pair, or raise its permission level
404 from the storeREST API not foundWooCommerce not installed, or permalinks set to Plain
Timeout / no routeStore unreachableHTTPS endpoint not publicly resolvable
Non-HTTPS store URLRejected before connectingWooCommerce's REST API does not support keys over plain HTTP

Two hard properties ride on the connect path. The store URL must resolve to a publicly reachable HTTPS host — URLs pointing at internal addresses are refused before any probing — and both halves of the key pair are stored encrypted. On success, the integration card flips to Connected and the sync starts.

What lands in Orbit from the store

Once connected, the WooCommerce sync rides the same normalized data path as the Shopify one: customers, orders, and products pull on a schedule into the tenant's contact store. The normalization is the point — a WooCommerce customer and a Shopify customer converge on the same contact row shape, so the flows you already have do not branch on provider.

The customer sync upserts an Orbit contact keyed on the WooCommerce customer id. The order sync projects each order's buyer — billing email or phone — into a contact, carrying order metadata (number, status, total, currency) into the contact's attributes, where the audience builder and flow branches can read them. Two pull-outs matter to recovery flows:

Guest checkouts are still addressable. A buyer who never created a WordPress account appears only in the order stream; the integration still lands them as a contact keyed on the order id, so the drip can target them, and the row merges by email or phone when they later create an account.

Repeat buyers merge. When an order carries the same customer id the customers sync created, keys prefer that id, and the buyer's history consolidates into one row instead of fragmenting per purchase.

Worked example: cart recovery on a WooCommerce store

The recovery flow is the same four steps as the Shopify playbook — the trigger surface differs in shape, not in kind.

1. Trigger on the cart event. WooCommerce installs register a webhook with the store (WooCommerce → Settings → Advanced → Webhooks) so order creation events reach Orbit as they happen; between deliveries, the scheduled sync closes any gap. Either way, a new order lands on a contact row with the order total, currency, and status in attributes — the properties your flow subscribes to.

2. Delay. Wait long enough for the buyer to finish unassisted. An hour is a reasonable starting point; an immediate send converts against people who were still mid-checkout.

3. Exit on self-completion. Before the send, check whether a post-abandonment order arrived for the same buyer identity. Because orders land on the same contact the cart carried, the check is a property read on one row, not a cross-system lookup.

4. Send the recovery template. WhatsApp requires a pre-approved template for business-initiated sends, so the recovery step is a template call with the cart fields as body parameters:

curl -X POST https://api.orbit.devotel.io/api/v1/messages/whatsapp \
  -H "X-API-Key: dv_live_sk_..." \
  -H "Content-Type: application/json" \
  -d '{
    "to": "+14155552671",
    "type": "template",
    "template": {
      "name": "cart_recovery",
      "language": { "code": "en" },
      "components": [
        {
          "type": "body",
          "parameters": [
            { "type": "text", "text": "{{cart_total}} {{currency}}" },
            { "type": "text", "text": "{{recovery_url}}" }
          ]
        }
      ]
    }
  }'

For the full flow-definition shape, start from the recipes in Five flow recipes and substitute the WooCommerce order trigger; the surface the send goes through is the WhatsApp channel. If you ran the Shopify playbook before, nothing else changes — same trigger shape, same exit check, same template.

Conversion measurement: the same five numbers, same meanings

Instrument the flow before you call it done. The five metrics from the Shopify playbook carry over unchanged, because none of them depend on where the store is hosted:

  • Recovery rate. The fraction of triggered recovery flows that end in an attributable order, on an attribution window you pick and hold constant. The headline metric; everything below explains it.
  • Early-exit rate. The fraction exiting at the self-completion check. A high exit rate with a low recovery rate means the delay is doing the converting; a near-zero exit rate with a low recovery rate means the message is weak.
  • Delivered and read rates on the recovery step. Per-recipient channel truth from the message log, split by destination market. A delivery dip in one market is a template or quality-rating problem, not a flow problem.
  • Opt-out rate on the recovery template. STOP responses attributed to the recovery send. A rising rate means the cadence or copy overreached the consent scope, and the fix is the message, not the targeting.
  • Trigger freshness lag. Time from store event to flow trigger. Sustained lag means the scheduled sync is carrying the load instead of the store webhook — re-register the webhook or verify the endpoint on the WooCommerce side.

Compliance posture: the controls stay tenant-owned

Self-hosting changes who answers the data-protection paperwork but not who holds the messaging posture. The compliance topics a hosted platform mandates against its app — data requests, redactions — are your store's to answer in WooCommerce, from your privacy policy, on your SLA. Inside Orbit, the controls that shape outbound messaging work the same on every channel and stay in your hands: your opt-out keywords, your quiet hours, your consent windows, your retention sweeps. The integration reads your store; the sending decisions follow the settings you own.

Build it

The connect walkthrough — key generation, validated paste, self-hosted failure modes — is on the WooCommerce integration page. The messaging surface the recovery step sends through is the WhatsApp channel, and the flow-definition patterns the trigger plugs into are in Five flow recipes. Generate a key pair, paste it in, and the first recovery send is an afternoon's work — the same playbook as the hosted platform, without the redirect.

Frequently asked questions

Does the WooCommerce route get the same flows as Shopify?

Yes. The normalized customer, order, and product models converge on the same contact rows, so abandoned-cart, post-purchase, and order-update flows run identically once the store is connected. Only the connect path differs — a validated REST API key pair instead of the OAuth popup.

Why is there no OAuth Connect button for WooCommerce?

WooCommerce is self-hosted, so there is no central OAuth authority to redirect through. You generate a REST API key pair in WordPress and paste it into Orbit instead, which also means there is no third-party app review to wait on.

Why does connect fail with a 401 or "credentials rejected"?

WooCommerce answered the validation probe with 401 or 403. Regenerate the key pair under WooCommerce → Settings → Advanced → REST API and confirm its permissions are at least Read. A 404 instead means the REST API was not found at that URL — WooCommerce not installed, or permalinks set to Plain.

Why does Orbit insist on an HTTPS store URL?

WooCommerce's REST API does not support sending API keys over plain HTTP — the secret would traverse in cleartext. The connect flow rejects non-HTTPS URLs before storing anything, and requires the URL to resolve to a publicly reachable host.

Do guest checkouts get recovery messages?

Yes. A buyer with no WordPress account still appears in the order stream; the sync lands them as a contact keyed on the order id, and the row merges by email or phone when they later create an account.

What happens if a store webhook delivery is missed?

The scheduled sync refreshes customers, orders, and products, so a missed delivery degrades freshness to the sync interval instead of losing the event. Re-registering the webhook in WooCommerce restores the real-time path.

The takeaway

Cart recovery does not belong to the hosted platforms. The WooCommerce integration puts a self-hosted WordPress store on the same normalized customer-order-product sync, behind a validated API-key connect with HTTPS enforcement and encrypted credential storage — so the four-step recovery playbook, its five measurement numbers, and its tenant-owned compliance posture carry over without modification. The WooCommerce integration page has the connect walkthrough; the WhatsApp channel docs carry the template-send surface the recovery step uses.

Published 6 September 2026.

WooCommerce Cart Recovery — the Same Playbook as Shopify, on an API Key — Orbit by Devotel