> ## Documentation Index
> Fetch the complete documentation index at: https://docs.utmkit.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Approved values

> Close a UTM parameter to a list of values you have approved, one parameter at a time, and know what retiring the last one does.

An approved value is one the workspace has decided is legitimate for a parameter: `newsletter`
and `google` for `utm_source`, say. Once a parameter has approved values, a link must pick one of
them. Until it has any, the parameter is **open**: it accepts anything the
[convention](/en/rules/the-convention)'s format allows.

Keep that sentence in mind. Approving your first `utm_source` does not add one permitted value;
it forbids every other one at once. That is what lets a workspace adopt the library one parameter
at a time: close `utm_medium` today without listing every `utm_term` you will ever use.

The library lives on the Rules page, [https://app.utmkit.co/rules](https://app.utmkit.co/rules), one card per parameter. Owners
and admins can approve and retire; members and viewers see the list.

## Approving values

On a parameter's card, type one value or several separated by commas and choose **Approve**. Each
value must already follow the convention — `Facebook` cannot be approved under a lowercase rule —
and approving something already approved changes nothing. The list is case-insensitive, so
`facebook` and `Facebook` cannot both be approved, but the check on a link is exact: under a
convention whose casing is `any`, a link carrying `Facebook` is refused when `facebook` is the
approved spelling. A card with nothing approved says so:
"No values approved, so this parameter accepts anything the format allows."

Approving changes what the next link may carry. Links already created are untouched.

## What a link sees

In block mode, a link with `utm_source=fb` in a workspace that approved `facebook` and
`newsletter` is refused with the list in the sentence: *utm\_source 'fb' is not approved in this
workspace. The approved values are: 'facebook', 'newsletter'.* In warn mode the link is created
and the same sentence is reported. Either way, whoever asked — a person or an assistant — knows
what to correct towards.

## Retiring a value

Each approved value has a **Retire** control. Retiring removes it from what the next link may
use; links already created keep working and keep the value. The
[audit](/en/rules/audit-existing-urls) is what finds links that no longer comply, and approving
the value again is the way back.

<Warning>
  Retiring the **last** approved value of a parameter does not tighten it. It opens it: with no
  approved values left, the parameter accepts anything the format allows. The console says so in
  the confirmation before it removes the value. Read that act as loosening, because that is what it
  does.
</Warning>

If a [dependency rule](/en/rules/dependency-rules) still allows the value under its own condition,
that rule is left alone: the value stays permitted under that pairing while the general library no
longer offers it. The confirmation says this too.

<Note>
  A member whose seat is [locked](/en/rules/member-locks) on a parameter may only pick from this
  list. Retiring a value takes it away from them for new links; approving one gives it back.
</Note>

## From the API and the MCP

`GET /api/v1/rules/values` lists the approved values per parameter, `POST /api/v1/rules/values`
approves values for one parameter (additive; repeats are no-ops) and
`DELETE /api/v1/rules/values/{id}` retires one — and retiring the last value opens the parameter,
exactly as in the console. Reads need `rules:read`, writes `rules:write`, and the writes also
require an owner or admin behind the token. The MCP tools are `list_approved_values`,
`approve_values` and `retire_value`, under the same permissions.