---
title: "Detach many variants from one supplier, by id or by filter"
method: DELETE
path: "/api/v1/inventory/suppliers/{supplier_id}/variants"
tags: ["suppliers"]
---

# Detach many variants from one supplier, by id or by filter

`DELETE /api/v1/inventory/suppliers/{supplier_id}/variants`

## Request

- Base URL: `https://api.app.tightly.io`
- URL: `https://api.app.tightly.io/api/v1/inventory/suppliers/{supplier_id}/variants`
- Auth: HTTP bearer

Detaches many variants from one supplier and answers 204 with no body.

Name them as `variant_ids` in a JSON body, or as a comma-separated `variant_ids` query parameter. Both are read on every request and the two lists are added together, so send one or the other rather than the same ids twice.

`filter_args` and `search` in the body select by query instead, the way the variants table does, with `exceptions` naming the ids to keep. When either is sent, the explicit list is not used.

Defaults are repaired the way remove_variant_from_supplier repairs them: a variant left without a default supplier takes the first of the suppliers it still has. Prepacks are pruned in the same call and a prepack left holding one variant or none is deleted.

An unknown supplier is refused 404.

Scope: `suppliers:write`, which includes `suppliers:read`.

## Path parameters

- `supplier_id` string, required

## Query parameters

- `variant_ids` string

## Headers

- `Tightly-Version` string
- `Idempotency-Key` string

## Request body

- DeleteVariantsFromSupplierRequest
  - `exceptions` string[], nullable
  - `filter_args` ProductsFilterArg[], nullable
    - `key` string, required
    - `operation` string, required
    - `value` unknown
  - `search` string, nullable
  - `variant_ids` string[]

## Response `204`

The pairs are gone. No body.

## Other responses

- `400`: A filter key, operation or value is not one the variants table takes.
- `401`: No usable key: malformed, unknown, revoked, expired or stopped. One refusal covers all five, telling a caller which is which maps the surface for them. A request with no Authorization header at all is refused 400 before any key is looked for.
- `403`: The key may not reach this operation. `scope_missing` when the key does not hold Suppliers; `ip_not_allowed` when the caller's address is outside the key's allowlist. There is no `organization_mismatch` on this resource: no supplier or contact route names an organisation in its path, so there is nothing for a key to disagree with.
- `404`: No supplier of this organisation has that id.
- `429`: The key has spent its allowance for this minute. 600 reads and 120 writes a minute, counted per key, refused calls included. `Retry-After` says how long to wait.
- `503`: The database is briefly out of reach, which is what a failover or a full connection pool looks like from outside. Wait the seconds `Retry-After` names and send the request again. A read is safe to repeat. A write is not, because the connection was lost in the middle of it, so read the object back before sending it a second time. Branch on the status rather than on `code`, which is `POSTGRES_UNAVAILABLE` from one of the two seams that raise this and `SERVICE_UNAVAILABLE` from the other.

---

[API](https://skmtc.dev/tightly/apis/tightly-api.md) · [All operations](https://skmtc.dev/tightly/apis/tightly-api/llms.txt) · [OpenAPI document](https://skmtc.dev/tightly/apis/tightly-api/revisions/199f7eb35afb?raw)