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

# Campaigns

> A campaign groups a workspace's links under one name and gives the report something to filter by.

A campaign is the container your links hang under. It does two things: it groups links so
"everything from the spring launch" is one list, and its name is the default `utm_campaign` of
the links created under it, so the report can be narrowed to that campaign.

Campaigns live at [https://app.utmkit.co/campaigns](https://app.utmkit.co/campaigns). Everyone in the workspace can see the list;
owners, admins and members can create, rename and delete. A viewer sees the list and nothing else.

## Creating a campaign

<Steps>
  <Step title="Open Campaigns and choose New campaign">
    Give it a name and, if you like, a description.
  </Step>

  <Step title="Check the derived value">
    After saving, the row shows the `utm_campaign` the campaign contributes, rewritten to follow the
    workspace's [convention](/en/rules/the-convention): "Spring Launch" becomes `spring-launch` under
    the default rules. That value is checked against the rules when you save. If `utm_campaign` has
    [approved values](/en/rules/approved-values), a name that does not produce one of them is refused,
    with the approved values in the message.
  </Step>
</Steps>

Names are unique per workspace and matched without regard to case. Asking for a campaign that
already exists gives you the existing one rather than a duplicate, which is why the console says
the campaign "is ready to use" either way. You can also create one by asking
[the assistant](/en/get-started/the-assistant) for a link under a new campaign.

## Renaming, and what renaming does not change

Edit a campaign to change its name or description. Renaming changes the default `utm_campaign`
for links created from now on. **Links already created keep the value they were born with**: it
is baked into their destination, already published to the edge and already counted in your
reports. Rewriting it would split a campaign's history in two at the moment somebody fixes a
typo. The editor says so before you save.

## The links of a campaign

Each row counts the links it holds and offers two shortcuts. **See its links** opens the links
list at [https://app.utmkit.co/links](https://app.utmkit.co/links) already narrowed to that campaign, and **See its numbers**
opens [the report](/en/analytics/the-report) filtered to it.

## Deleting a campaign

Deleting a campaign removes the grouping and nothing else. Its links keep working, keep
redirecting and keep the `utm_campaign` they carry; they simply no longer belong to a container.
The confirmation states how many links that is, so a campaign holding forty links reads
differently from an empty one.

<Note>
  A campaign whose name today's rules would refuse is still listed as it is. The rules apply when a
  name is chosen, not retroactively; the [audit](/en/rules/audit-existing-urls) is what finds links
  that no longer comply.
</Note>

## From the API and the MCP

`GET /api/v1/campaigns` lists the workspace's campaigns with their link counts,
`POST /api/v1/campaigns` creates one (a repeated name returns the existing campaign),
`GET /api/v1/campaigns/{id}` reads one, and `PATCH /api/v1/campaigns/{id}` renames or
re-describes it — both fields are optional on `PATCH`, and existing links keep their
`utm_campaign` exactly as in the console. There is no delete operation; deleting is console work.
Reads need `campaigns:read` and writes need `campaigns:write`. Over the MCP the tools are
`list_campaigns`, `get_campaign` and `create_campaign`, under the same two permissions.