# Delete and erase through the API

What each DELETE call on the OLET API removes, what it cleans up, and why erasing a customer cannot be undone.

Source: https://getolet.com/resources/developers/delete-and-erase/
Updated: 2026-10-15

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](/resources/developers/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](/resources/developers/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](/resources/developers/authentication/).

## Where to go next

See [write a whole product in one request](/resources/developers/write-a-product/) for creating and changing products, or [errors](/resources/developers/errors/) for every status code.