Skip to main content
A poster gets one URL. When you promote an app, that URL has to send an iPhone to the App Store or your app, an Android phone to Play or your app, and everyone else to a web page. In UTMKit that is one link with up to three destinations.

​
From the console

A link always has a web destination. Beside it you can add an iOS destination and an Android destination, each optional and independent.
  • Creating a link in the chat: tell the assistant the iOS or Android address along with the rest. See Create a link.
  • An existing link: open Links, choose Edit, and fill in iOS destination or Android destination. Leave a field blank to remove it.
From then on an iPhone lands on the iOS destination, an Android phone on the Android destination, and everyone else — a laptop, a bot that does not present itself as a phone, a browser we cannot recognise, an iPad asking for desktop websites — on the web destination. A platform you did not set falls back to the web destination, never to the other platform.

​
What a platform destination can be

An https:// address only: your app’s own link, or its store page on apps.apple.com or play.google.com. A custom app scheme such as myapp:// is refused, for four reasons:
  1. We could not screen it. Destinations are checked against abuse lists before they become links, and those lists hold web addresses. A scheme would pass as “clean” unchecked.
  2. We could not watch it. The daily destination check dials the address to see that it still answers. A scheme names no server to dial.
  3. The phone decides which app opens. If two apps claim the same scheme, the operating system picks one, not necessarily yours.
  4. A phone without the app shows an error. A redirect to a scheme has no fallback.
A store address in its scheme form (itms-apps://, market://) is refused too, and the console names the https:// form, which opens the store on a phone and still works on a desktop.

​
Governed like the web destination

A platform destination is screened with the same rules and refusals as the web destination, the daily check watches it, and a change to it appears in the activity log. Your UTMs are applied to all three destinations; on a Play store address they are also folded into the store’s referrer parameter, so your app learns on first launch which campaign brought the install. The App Store has no equivalent.

​
The counts

Open the report and group by destination. Each row names where visitors were sent — the App Store, Play, your app, or the web — with its count, under the same filters and exclusions as every other grouping. The client report, the API and the MCP offer it too.
This is routing plus counting, not install attribution. We can say how many phones we sent to Play; we cannot say which of them installed, or that the person who installed is the one who clicked. That needs an SDK inside your app, which a short link cannot provide. Whether your app opens or the store page shows is between the address you chose and the visitor’s phone.
Deep links are on every plan; a routed visit is one click, metered like any other.

​
From the API and the MCP

The platform destinations are two fields, ios_url and android_url, on POST /api/v1/links and PATCH /api/v1/links/{id}. Both accept an https:// address only, with the refusals above. On a PATCH, null (or a blank) clears that platform destination; a field left out is left as it is. Both operations require the links:write permission. The MCP tools create_link and update_link (also links:write) do not take the platform fields today; set them through the API or the console.