What the WooCommerce Dual API Plugin Changes

If an extension uses WooCommerce’s experimental Dual API, the move to WooCommerce 11.2 needs a compatibility check. The API engine is becoming a separate plugin, and the earlier product and coupon proof-of-concept endpoints are being removed. Installing the plugin does not restore those endpoints. For teams evaluating the engine, the change makes it easier to install and update independently, but it remains experimental. I would keep the evaluation on a disposable store and start by listing exactly which parts the extension uses. That distinguishes an engine dependency from an endpoint that now needs to be replaced.

Check whether your extension uses the experiment

Even when a feature is labeled experimental, shipping it inside core can feel like an endorsement of its eventual shape. Integrators may build against it, hosts may assume it needs support, and stores may carry code they never use.

A separate plugin says something more precise: this capability is available to evaluate, but adoption is a choice. Its version can move independently, while developers must account for incompatible changes.

Define the workflow being evaluated

I would not install the plugin just to see new endpoints. I would write down the use case, entities involved, authentication model, expected writes, rollback path, and what evidence would make the experiment worth continuing.

For commerce APIs, I pay special attention to price, inventory, coupons, taxes, customer identity, and order side effects. A proof of concept should use synthetic products and isolated credentials, never the live catalog as a convenient fixture.

Plan how to remove the prototype

The ability to delete a prototype without leaving hidden state is a feature. Before a pilot, I want to know which tables, options, webhooks, scheduled actions, permissions, and external consumers it creates. Uninstalling code does not automatically unwind those relationships.

I also avoid letting an experimental response shape become the internal domain model. A small integration layer can isolate the experimental response format so changes do not spread through the rest of the application.

Test the store rules that must remain correct

• A product update cannot silently change price or stock.
• A coupon cannot become broader than its configured restrictions.
• Unauthorized clients receive no sensitive catalog or customer data.
• Retries do not duplicate writes or webhooks.
• Failures leave an explainable state.
• Disabling the plugin restores the previous path cleanly.

Those invariants matter more than broad endpoint coverage during the first evaluation.

Track plugin versions and dependencies

A dedicated package can publish its own changelog, compatibility statement, and issue template. Testers can report the exact plugin version separately from the WooCommerce version. Maintainers can ship a correction without waiting for the next core cadence.

The tradeoff is another dependency to maintain. Teams need an owner, update policy, and environment matrix instead of assuming the feature inherits core’s operational maturity.

Keep the evaluation separate from production

The WooCommerce engineering announcement explains the move and the removal of the earlier proof of concept. Separating the experiment creates room to learn without making every store carry the learning process.

Good platform stewardship sometimes means narrowing what core promises. Developers can evaluate the API separately without treating it as a supported part of every store.

I would keep production data out of the learning loop. A convincing API demo often needs realistic products, coupons, and order rules. I would create synthetic records that preserve those shapes without copying customer data or connecting live webhooks. Test credentials should be scoped to the disposable environment, and outbound email, payment capture, fulfillment, and analytics integrations should be disabled or pointed at sandboxes.

I would also record every consumer built during the experiment. A temporary command-line script can quietly become a business dependency if staff start using it for daily work. Before the pilot ends, each consumer should be retired, promoted with a documented maintenance plan, or explicitly accepted as temporary with an expiry date. A separate plugin is easier to disable, but any scripts or staff workflows that depend on it must be addressed too.

I would pin the plugin version during evaluation and review its changelog before every update. Experimental does not mean careless; it means change is expected. A controlled upgrade cadence lets the team learn from that change without allowing an unattended update to invalidate test results or surprise a dependent prototype.

Finally, I would keep the plugin off environments that are not participating in the trial. Reducing installation scope reduces patching work, ambiguity during incidents, and the chance that someone mistakes an experimental endpoint for a supported integration surface.

Choose one small test workflow

Start by checking the official migration notes against the extension’s dependencies and endpoints. If there is a valid use case for continued evaluation, pin a plugin version and use synthetic data on a disposable store. Test one workflow with clear expected results and a removal plan. Do not promote an experimental integration because a demonstration works. WooCommerce explicitly warns that this API can change incompatibly and should not be used in production extensions.

Photo by Startup Stock Photos on Pexels.