Skip to main content
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’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, 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. 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 is what finds links that no longer comply, and approving the value again is the way back.
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.
If a dependency rule 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.
A member whose seat is locked 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.

​
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.