WooCommerce 10.7 Gave You a Typed Fulfillment API — Send Shipped Events to Ads

What WooCommerce 10.7 Actually Shipped for Fulfillment

Three PRs, a new taxonomy, and typed PHP methods that turn shipping data from plugin-specific metadata into a first-class WooCommerce API.

WooCommerce 10.7 landed on April 14, 2026 with 175 merged pull requests from 66 contributors. The headline was performance — HPOS order queries on the REST API dropped from 271 database queries per request to 132 through cache priming, a 51% reduction (WooCommerce Developer Blog, 2026). But buried in the release were three fulfillment-specific changes that matter more for ad platform integration than any performance optimisation.

PR #63485 registered the fulfillments data store via the woocommerce_data_stores filter. This means any extension or pipeline can hook into WooCommerce’s standard data store pattern to read and write fulfillment data — the same way you’d interact with orders, products, or customers.

PR #63573 added typed PHP methods: get_tracking_number(), set_tracking_number(), get_shipping_provider(), and set_shipping_provider(). These are not shorthand wrappers around post meta calls. They’re typed methods on a proper data store, which means they validate inputs, follow WooCommerce’s data layer conventions, and are safe to use in hooks without worrying about meta key collisions across plugins.

PR #63516 introduced a FULFILLMENT order note group constant in OrderNoteGroup. Fulfillment lifecycle events — tracking added, shipped, provider updated — now log as structured order notes in their own group, separate from payment notes, customer notes, and internal notes.

WooCommerce 10.7 shipped typed PHP methods get_tracking_number(), set_tracking_number(), get_shipping_provider() and set_shipping_provider() via a stable WC_Data_Store — standardising fulfillment data that was previously locked in shipping-plugin-specific tables.

The release also added custom shipping providers under Settings > Shipping > Shipping Providers, backed by a new wc_fulfillment_shipping_provider taxonomy. Each provider supports a tracking URL template, and WooCommerce automatically converts tracking numbers into clickable links in customer emails and order screens (WooCommerce, 2026).

The Post-Purchase Signal Gap in WooCommerce

Almost every WooCommerce store sends Purchase to Google Ads and Meta CAPI — and then the signal goes dark.

The customer journey from a WooCommerce store’s perspective doesn’t end at checkout. After Purchase comes Shipped, In Transit, Delivered, Used, Retained, and — in the worst case — Returned or Refunded. Each of these states carries information about customer quality that the initial Purchase event doesn’t.

Most WooCommerce stores send exactly one event to their ad platforms: Purchase. The customer completes checkout, the pixel fires, CAPI receives the server event, and the ad platform credits the conversion. Everything after that — the shipping, the delivery, whether the customer kept the product — stays inside the store’s internal systems and never reaches the algorithm.

This matters because the Purchase event treats every buyer equally. The customer who receives their order, keeps it, and reorders in three months looks identical to the customer who receives their order, opens a return request the same day, and gets a full refund. From Smart Bidding’s perspective, both are conversions of equal value.

The reason most WooCommerce stores don’t send post-purchase signals isn’t a lack of awareness — it’s a lack of standard data access. Before 10.7, tracking numbers lived in ShipStation’s _wc_shipstation_shipped_item_count meta, or Shippo’s _shippo_order_metadata, or AST’s _wc_shipment_tracking_items serialised array. Every shipping plugin stored its data differently. There was no standard API to say “give me the tracking number for this order.”

You may be interested in: WooCommerce Add-to-Cart as Primary Conversion Pollutes Smart Bidding

Why Post-Purchase Signals Beat Purchase for Smart Bidding

Feed Smart Bidding a Delivered event and it learns to find customers who complete the full journey — not just the checkout.

Smart Bidding optimises toward whichever conversion types you include in the Conversions column (Google Ads Help, 2026). If that column contains only Purchase events, the algorithm optimises for checkout completions. If it also contains Delivered events, the algorithm sees which clicks produce customers who receive and keep their orders.

The difference is signal quality. A Purchase event fires at checkout — the earliest possible post-conversion moment. It contains no information about whether the order was fulfilled correctly, whether the customer experienced delivery problems, or whether a return followed. A Delivered event fires days or weeks later, after the customer has received the product and the return window has passed or begun. The correlation between Delivered and long-term customer value is stronger than the correlation between Purchase and long-term customer value.

Google Ads explicitly supports offline conversion imports for exactly this purpose. Uploaded offline conversions typically appear in reporting within 3–24 hours, and Smart Bidding starts incorporating the signal over 1–3 weeks as the algorithm updates its model (NPPR Team, 2026). The recommendation is to upload at least daily and to run the conversion as Secondary before promoting it to Primary, so the algorithm learns the signal pattern without destabilising existing campaigns.

Google Ads Smart Bidding optimises toward whichever conversion types you include in the Conversions column — feeding it post-purchase signals like Delivered teaches the algorithm to find customers who complete the full lifecycle, not just the checkout.

Meta CAPI accepts custom events with the same logic. A server-side Shipped event with the order ID as event_id gives Meta’s algorithm a second signal in the conversion chain. Google’s Journey-Aware Bidding, announced May 7, 2026, explicitly lets multiple funnel stages influence bids (Passionfruit, 2026) — post-purchase stages directly benefit from typed fulfillment data flowing into the conversion stream.

Before 10.7: Plugin-Specific Tables and Custom Code

Every shipping plugin stored tracking data differently — building a post-purchase event pipeline meant writing custom integration code for each one.

Before WooCommerce 10.7, a store that wanted to fire a Shipped event to Google Ads had to solve the data access problem first. Where is the tracking number? The answer depended entirely on which shipping plugin the store was running.

ShipStation stored its data in custom order meta keys including _wc_shipstation_shipped_item_count. Shippo used its own metadata structure. AfterShip stored tracking via its own REST API. AST (Advanced Shipment Tracking) used a serialised _wc_shipment_tracking_items array in post meta. Each plugin’s data format was different, and none of them exposed their data through a common WooCommerce API.

For a store running one shipping plugin, the custom code was manageable — you’d write a hook that read that plugin’s specific meta key and fired the downstream event. But the code was fragile. If the shipping plugin updated its data structure, the integration broke. If the store switched shipping providers, the integration needed rewriting.

Shipping Plugin	Tracking Data Location	API Surface Before 10.7	Standard WC_Data_Store Compatible
ShipStation	Custom order meta (_wc_shipstation_*)	Plugin-specific REST endpoints	No (requires adapter)
Shippo	_shippo_order_metadata	Shippo API	No (requires adapter)
AST / AST PRO	_wc_shipment_tracking_items (serialised)	REST API (/wc-shipment-tracking/v3/)	Compatibility confirmed with WC 10.7
AfterShip	AfterShip API + local cache	AfterShip REST API	No (requires adapter)
WC 10.7 Native	WC_Data_Store (fulfillments)	Typed PHP methods + data store filter	Yes (native)

WooCommerce 10.7’s fulfillment data store solves this by providing a single API surface. Any plugin that adopts the new data store writes tracking data through the standard methods. Any pipeline reading tracking data uses the same get_tracking_number() call regardless of which plugin originally set the value. The fragmentation doesn’t disappear overnight — adoption takes time — but the standard now exists.

How to Fire a Shipped Event From the New API

The architectural punchline: listen for the tracking number being set, read the typed data, and fire the event server-side to every ad platform simultaneously.

The implementation pattern for a server-side pipeline is clean. When a tracking number is set via set_tracking_number(), the pipeline reads the tracking number and shipping provider using the typed methods, constructs a Shipped event payload, and sends it to Google Ads (as an offline conversion import), Meta CAPI (as a custom event), and BigQuery (as a raw event row).

The FULFILLMENT order note group constant means fulfillment-related actions are now logged as structured notes. A pipeline can subscribe to the order note creation hook, filter for the FULFILLMENT group, and trigger downstream events based on the note content — without parsing free-text notes to guess whether a shipment happened.

For Google Ads, the Shipped event maps to an offline conversion import. Enhanced Conversions for Leads is now the recommended path — Google deprecated the manual GCLID-only approach for new advertisers (NPPR Team, 2026). The GCLID or gclid value captured at click time and stored in the WooCommerce order meta connects the shipped event back to the original ad click. The conversion value can be set to the order total, creating a post-purchase value signal that updates Smart Bidding’s model for which clicks produce complete fulfilment cycles.

For Meta CAPI, the Shipped event fires as a custom server event with event_name set to a Shipped convention, the order ID as event_id for deduplication, and the tracking number and carrier as custom_data fields. Meta’s algorithm doesn’t natively recognise “Shipped” as a standard event — but custom events still feed the conversion model when associated with a pixel-tracked user.

For BigQuery, the Shipped event row joins against the Purchase event row on order_id, creating a complete click-to-delivery timeline. This is where the real analytics value lives: measuring the gap between purchase and delivery by carrier, by product category, by shipping zone — and correlating delivery speed with return rates and customer lifetime value.

You may be interested in: A Third of Your GA4 Numbers Are Modelled — WooCommerce Stores Can’t See Which

The Beta Caveat and What It Means for Production

WooCommerce marks fulfillments as beta — the API surface may change, but the architectural direction is locked in.

WooCommerce explicitly marks the fulfillments system as beta in 10.7. The typed API, data store registration, and custom shipping provider settings are functional, but the namespace already moved from AutomatticWooCommerceInternalFulfillments to AutomatticWooCommerceAdminFeaturesFulfillments in this release (Peak Digital, 2026) — extensions using the old path need updating.

Beta means the API surface may see breaking changes in future releases. Method signatures could change. The data store schema could evolve. The taxonomy backing custom shipping providers could be restructured.

What won’t change is the direction. WooCommerce committed to making fulfillment a first-class data surface. The data store pattern, the typed methods, and the order note group are architectural decisions, not experimental features. Stores and pipelines that build against the new API today get early access to the standard that every WooCommerce shipping integration will eventually adopt.

The practical recommendation: use the new API in production for reading fulfillment data and firing downstream events, but build an abstraction layer between your pipeline and the WooCommerce API surface so that method signature changes in future releases require updating one adapter, not every integration point.

The Transmute Engine™ subscribes to WooCommerce fulfillment hooks at the server level, reads tracking data through the typed API, and routes Shipped events to Google Ads, Meta CAPI, TikTok Events API, and BigQuery in parallel — turning the post-purchase signal surface from dark to instrumented without touching the store’s frontend or requiring plugin-specific integration code.

Key Takeaways

• WooCommerce 10.7 standardised fulfillment data: Typed PHP methods (get_tracking_number, get_shipping_provider) and a WC_Data_Store registration mean tracking data is no longer locked in plugin-specific tables.
• Most stores send only Purchase to ad platforms: The post-purchase signal surface — shipped, delivered, refund-free — has been dark because the underlying data had no standard API. WC 10.7 changes that.
• Post-purchase signals improve Smart Bidding: A Delivered event tells the algorithm which clicks produce customers who complete the full journey — a stronger signal than Purchase alone.
• The new API enables server-side event pipelines: Any pipeline can now read fulfillment data from a stable data store and fire enriched offline conversion events to every ad platform and BigQuery simultaneously.
• Beta means the direction is set, not the details: The API surface may evolve, but the architectural commitment to first-class fulfillment data is locked in. Build an abstraction layer and start using it now.

References

• WooCommerce Developer Blog — WooCommerce 10.7: Performance, Analytics, and a Better Store API (April 2026)
• WooCommerce Developer Blog — WooCommerce 10.7: What’s Coming for Developers (April 2026)
• WooCommerce — WooCommerce 10.7: 51% Fewer Queries, a Real Fulfillment API, One Important Cache Fix (May 2026)
• Peak Digital — WooCommerce 10.7.0 Technical Update: Performance and Store API (April 2026)
• Google Ads Help — Offline Conversion Imports FAQs (2026)
• NPPR Team — Google Ads Offline Conversion Imports: Setup Guide 2026 (April 2026)
• Passionfruit — Google Ads Journey-Aware Bidding: 2026 Advertiser Guide (May 2026)
• Zorem — AST PRO: Shipment Tracking for WooCommerce, Compatible with WC 10.7 (May 2026)

If your WooCommerce store sends Purchase to your ad platforms and nothing after, your algorithms are optimising from an incomplete picture. Seresa builds server-side pipelines that hook into WooCommerce’s fulfillment API, read tracking data at the event level, and route Shipped and Delivered signals to Google Ads, Meta CAPI, and BigQuery — so Smart Bidding learns from the full customer journey, not just the checkout.