Skip to main content
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. 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

1

Open Campaigns and choose New campaign

Give it a name and, if you like, a description.
2

Check the derived value

After saving, the row shows the utm_campaign the campaign contributes, rewritten to follow the workspace’s 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, a name that does not produce one of them is refused, with the approved values in the message.
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 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. Each row counts the links it holds and offers two shortcuts. See its links opens the links list at https://app.utmkit.co/links already narrowed to that campaign, and See its numbers opens 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.
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 is what finds links that no longer comply.

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