---
title: "Set Requirements State Bulk"
method: POST
path: "/marketing/guidelines/requirements/state"
tags: ["marketing-guidelines"]
---

# Set Requirements State Bulk

`POST /marketing/guidelines/requirements/state`

Turn several requirements off, remove them, or put them back, in one press.

The library is long enough that the interesting selections are not one row: a search that finds
seventeen restatements of the same enforcement note is a single decision, and making it
seventeen times is how it does not get made.

**Removal stays archival.** `ARCHIVED` keeps the requirement and every version of it readable,
which is the point on regulated compliance material; there is no hard delete here.

One requirement's refusal never fails the batch, and every id gets an outcome — the three
refusals are `refuse_state_change`, the same function the rollout-consistency worklist uses, so
the two surfaces cannot drift about what a person may do to a requirement.

## Request body

- BulkSetRequirementStateRequest — Turn several requirements off, remove them, or put them back. Same rules as the single-requirement form, which is why the state field carries the same refusal: SUPERSEDED is what a newer decomposition writes, never a person. The cap is not arbitrary. Each requirement takes a lock on the live library for the whole batch and costs one subtransaction id, and Postgres spills its per-backend `subxids` array past 64 — at which point every other backend's visibility checks start hitting `pg_subtrans`, which is a cluster-wide problem rather than a slow request.
  - `requirement_ids` string[], required
  - `state` 'active' | 'disabled' | 'archived' | 'superseded', required — Whether a requirement is in the working library, and if not, why not. All four are recorded as revisions, so every one of them is reversible and readable. ARCHIVED and SUPERSEDED are deliberately distinct: ARCHIVED is a person deciding this obligation does not apply to them, SUPERSEDED is a newer decomposition of the same guideline taking over. A regeneration must never overwrite the first with the second — that would erase a human decision.
  - `change_note` string, nullable

## Response `200`

Successful Response

- BulkRequirementStateResponse
  - `applied` integer, required
  - `skipped` integer, required
  - `outcomes` BulkRequirementStateOutcome[], required
    - `requirement_id` string, uuid, required
    - `applied` boolean, required
    - `state` 'active' | 'disabled' | 'archived' | 'superseded', required — Whether a requirement is in the working library, and if not, why not. All four are recorded as revisions, so every one of them is reversible and readable. ARCHIVED and SUPERSEDED are deliberately distinct: ARCHIVED is a person deciding this obligation does not apply to them, SUPERSEDED is a newer decomposition of the same guideline taking over. A regeneration must never overwrite the first with the second — that would erase a human decision.
    - `reason` string, nullable, required

## Other responses

- `422` — Validation Error

---

[API](https://skmtc.dev/kobaltlabs/apis/fastapi.md) · [All operations](https://skmtc.dev/kobaltlabs/apis/fastapi/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/kobaltlabs/fastapi/revisions/3ff4c0bd276b/schema)