Delete and erase through the API

The OLET API has a DELETE for products, brands, categories, tags, suppliers and customers. Each one answers 204 with no body, needs the catalog:write scope (or customers:write for customers), and cleans up whatever pointed at the thing you deleted. The deletes are soft: the row is kept but hidden, so sales and reports that refer to it keep working.

What happens when I delete a product

DELETE /products/{id} removes the product. It refuses with:

• 422 UNPROCESSABLE for a gift card product.
• 409 CONFLICT if the product is a component of a composite product.
• 409 CONFLICT if it still has active variant children.

What happens when I delete a brand, category, tag or supplier

Each delete runs as one step, matching what the back office does.

• Brand. The brand is removed and every product that used it is left with no brand.
• Category. The category is removed and its products move to the system “Other Products” category. It refuses with 409 CONFLICT for a system category, for the reserved gift cards category, and for a category that still has live subcategories.
• Tag. The tag is removed from every product that carried it.
• Supplier. The supplier is removed from every product that carried it. A purchase order that named this supplier keeps its reference to the deleted supplier.

Changing a product this way gives it a new version, so every affected product shows up again in your next poll. Deleting a brand used by thousands of products means thousands of rows to re-sync. See pagination and polling.

Deleting an id that is unknown, belongs to another store, or is already deleted answers 404 NOT_FOUND.

What happens when I erase a customer

DELETE /customers/{id} needs the customers:write scope and permanently erases the customer’s personal details. It cannot be undone.

• The customer is marked deleted and the personal details are scrubbed: name, email, phone, address and the rest.
• The customer_code is replaced with a placeholder, so you can no longer look the customer up by the code you created them with. Keep your own mapping if you need to match records later.
• The customer’s version moves, so the erasure reaches your next poll as a tombstone when you use include_deleted=true.
• Sale history survives. Every past sale still resolves, shown against the anonymized customer, so reports and refunds keep adding up.

The walk-in customer is a system record and cannot be deleted: it answers 409 CONFLICT. Customer calls share a smaller rate limit than the rest of the API, see rate limits.

Because the data is gone for good, ask for confirmation in your own app before you call it. A key with customers:write can do it, so create keys with only the scopes they need. See authentication.

Where to go next

See write a whole product in one request for creating and changing products, or errors for every status code.