Skip to main content
Every other number in UTMKit is a click, and a click is not a result. A conversion is what happened next: the visitor who arrived through one of your links bought something, signed up, or became a lead. Your own systems know when that happens — the checkout, the signup form, the CRM — and a conversion is your server telling UTMKit about it, so the number lands beside the click that caused it. Conversions are reported through the API only. There is no form in the console and no MCP tool, because a conversion is your server’s event, not something a person types in. Nothing is put on the visitor’s browser; the redirect sets no cookie. Instead, once your workspace holds a token that may report conversions, every link’s destination carries a small _link reference naming the short link it came from — except a WhatsApp click-to-chat link, whose chat window has nothing to read it. Your landing page reads it, and your server sends it back with the first conversion for that customer. From then on UTMKit remembers which link brought that customer, so a purchase months after the signup can be reported with the customer’s identifier alone and still counts for the link that started it. That memory is also the only way a conversion from a WhatsApp link can be reported: with the customer’s identifier, against the link an earlier conversion named. Some rules worth knowing before you wire it:
  • Each conversion carries an identifier you choose. Reporting the same one twice records it once and answers as accepted. A retry is correct behaviour, so it is safe to automate.
  • A link that was withdrawn still takes conversions, and a deleted one as long as one of its clicks is still stored. The click happened and so did the result.
  • A value and a currency are kept exactly as given. Nothing is converted between currencies.
  • The workspace comes from the token. A reference to another workspace’s link is refused exactly as an unknown link would be, so a token can never write into someone else’s numbers.
  • Conversions count as tracked events, like clicks, towards your plan’s allowance, and each token has a limit on how many it may report in a window; a refusal says when to retry. See the plans page for the allowance.
  • A conversion is not an activity-log entry. It is a fact about a visitor, not a change a member made.

​
The token

Conversions need an API token with the conversions:write permission, minted on the tokens page like any other. A token holding only that permission can do nothing else — it cannot list, create or delete links — which is what makes it safe to hand to a client’s developer. The token’s last-used time on that page tells a working integration from a silent one.

​
Where conversions show

The report has a Conversions tile, with the total value when every conversion shared one currency, and a conversions column in its table. A conversion counts in the period it happened, whichever period its click was in, and the page says so beside the number. Grouped by day or by any UTM parameter, each row carries its conversions; grouped by country, device, referrer, trigger, event type or destination, the column shows a dash, because a conversion never saw the browser. A period with no conversions reads zero rather than hiding the column: a campaign that produced nothing is the finding. The same numbers appear on the client report and in the scheduled report mail.

​
From the API

Your server reports a conversion with POST /api/v1/conversions, using a token that carries the conversions:write permission. The API reference describes the fields and the two answers: created, or already recorded when the call is a retry. There is deliberately no MCP tool for conversions.