The two ways this goes wrong
WooCommerce's REST API exposes a single delete endpoint for products -- DELETE /wp-json/wc/v3/products/{id} -- and it behaves very differently depending on one optional parameter. Leave force unset or set it to false, and the product is moved to the WordPress trash, exactly the way a regular post would be if you clicked "Move to Trash" in the admin. Set force=true, and the product -- along with its variations, if it's a variable product -- is deleted outright, with no trash, no undo, and no recovery path short of restoring from a site backup.
That single parameter is the source of two completely different support tickets, and most teams eventually run into both.
Failure mode one: "I deleted it, but it's still showing up"
Someone builds a cleanup automation -- a scheduled script, a Zapier or Make scenario, a one-off bulk operation run from the WooCommerce REST API -- intending to permanently remove discontinued products. They call the delete endpoint without ever touching force, which means every one of those products quietly moved to the trash instead of actually disappearing.
The product vanishes from the live storefront, which looks like success. But it's still sitting in the WordPress admin trash, which means it's still technically a record in the database. If that store also runs a Google Shopping feed export, a sitemap generator, or any custom script that queries posts without explicitly excluding trash status, trashed products can keep leaking into places they shouldn't -- stale listings in a product feed, phantom entries in an export, SKUs that still "exist" as far as some other integration is concerned.
Failure mode two: the one that actually hurts
The more damaging version runs the other way. A lot of example code floating around in API docs, forum answers, and copied Postman collections already has force=true hardcoded into the request, because that's what you'd want for a genuine one-time cleanup. Someone adapts that example for a routine task -- clearing out a batch of test products, say -- without registering what force=true actually commits to, and runs it against more records than they meant to.
There's no WooCommerce-level undo for that. The products, their variation records, and their image associations are gone. The only way back is a full site or database backup from before the call ran, and only if one exists and is recent enough to not cost a day of sales data and content changes in the process.
The SKU wrinkle that makes this worse
Trashed products still hold onto their SKU, since they technically still exist in the database. That means if someone tries to recreate a "deleted" product with the same SKU -- not realizing the old one only got trashed -- the create call fails with a duplicate SKU error. This is frequently how teams first discover that their cleanup script was never actually deleting anything: the trash-vs-delete confusion surfaces as a baffling SKU conflict days or weeks later, not as an obvious failure at the time the script ran.
What to actually do about it
Treat force as a decision you make on purpose every time you write a delete call, not a default you inherit from whatever example you copied it from:
For routine content management -- removing a product from sale, cleaning up a listing -- leave force unset and let it trash normally. Then handle permanent removal the way WordPress already expects: empty the trash on a schedule, which gives you a recovery window (30 days by default) before anything is actually gone for good.
For genuine bulk cleanup where permanent deletion is the actual goal, set force=true deliberately, and run a dry pass first that only logs the product IDs your filter would match, before switching the same script over to actually delete them. That one extra step -- log, review, then delete -- is the difference between a cleanup script and an incident.
And if you're chasing down a duplicate-SKU error on a product you're sure you deleted, check the trash before assuming the SKU is corrupted or duplicated somewhere else -- it's very likely sitting right there, exactly where it was left.
This same trash-before-permanent-delete pattern shows up well beyond WooCommerce -- see how Freshdesk handles ticket deletion for a near-identical recoverable-for-a-window design in a completely different product. For the full picture of what WooCommerce's product API supports, start from the WooCommerce application overview, or see the Delete a Product integration details for the exact request behavior described here. More breakdowns like this one are in the implementation guides.