The experimental WooCommerce Dual API is moving out of core in 11.2. Installing its separate plugin does not bring back the proof-of-concept product and coupon endpoints. If an integration depends on those routes, identify and replace that dependency before updating the environment.
As of September 29, 2026, 11.2 is a prerelease, with release week planned for October 6. This is preparation guidance, not an instruction to install a beta on a live store. Check the official prerelease notes before scheduling deployment.
Who Is Actually Affected?
The September 28 announcement describes an opt-in experimental feature. It does not say the normal WooCommerce REST API or Store API is being removed. The separate engine requires WooCommerce 11.2 or later and PHP 8.1 or later. WooCommerce explicitly advises against using this experimental API in production extensions.
Start with the developer who owns custom integrations. Ask whether any extension enabled the Dual API feature or calls its experimental endpoints. A GraphQL dependency somewhere in your stack does not automatically prove it is this particular API.
Make a Caller-to-Route Inventory
Create one row for each client: scheduled inventory importer, internal dashboard, product editor, or prototype agent. Record the requested route, operation, authentication method, owning repository, and whether anyone relies on its result. Keep credential values out of the inventory.
An illustrative case is an internal product dashboard reading a demo route while a separate stock worker uses the supported REST API. Those are different migration scopes. Do not rewrite the stock worker merely because both applications interact with WooCommerce.
Ask the developer to search configuration and source code for the exact routes found in request logs. Review environment variables and background workers as well as the visible WordPress plugin list. Missing traffic during a short observation window does not rule out a weekly task.
Verification record for WooCommerce Dual API Moves to a Plugin: What to Check Before 11.2. Fill in your own evidence.
Choose the Destination Before Changing Dependencies
For production work, map the required operation to a supported interface and document any gaps. A read-only dashboard may need fewer fields than a catalog synchronization process. Confirm pagination, filtering, authentication, and error handling rather than treating matching JSON field names as full compatibility.
For an isolated experiment that genuinely needs the new engine, follow the repository documentation linked from the announcement. The extension must supply its own endpoint. Pin the tested versions and keep an explicit decision about when to abandon or revise the experiment.
Use the custom integration checklist to define success at the business-record level. A successful HTTP request does not establish that the right products or permissions were used.
Rehearse the Change With Synthetic Records
- Capture a baseline response for a small synthetic catalog and an account with limited access.
- Test the replacement request against the same records in staging.
- Compare identifiers, pagination boundaries, missing records, and permission failures.
- Stop or isolate old callers before allowing a replacement writer to run. Avoid two writers updating the same stock values.
- Keep the previous code and a clear restoration procedure, without assuming a code rollback reverses data already written.
The release decision should name every affected caller and its tested replacement. If the dependency cannot be identified, HandL WP can investigate the integration before an update turns an undocumented experiment into a store outage.
References checked September 29, 2026. Diagrams and examples are explanatory, not measured customer results.