Skip to main content

Linking to plans

Every plan comes with two links:

FieldExampleOpens
webUrlhttps://kamee.fit/plans/{id}The plan's page on kamee.fit
appUrlkamee://plan/{id}The plan inside the Kamee mobile app

Default to webUrl​

Use webUrl unless you have a specific reason not to. It always works, everywhere — on desktop, on mobile, in an email, inside a webview. The page it opens already offers app and app-store links, so a person who wants the app still gets there in one more tap.

<a href={plan.webUrl}>{plan.title}</a>

That is the whole integration for most partners.

When appUrl is worth it​

appUrl is a custom-scheme deep link. It opens the plan directly in the Kamee app, which is a genuinely better experience — but only if the app is installed.

If it is not installed, the behaviour is bad and varies by platform: the browser may show a scheme error, do nothing at all, or navigate to an error page. There is no reliable cross-browser way to detect the failure, and no way to detect installation before navigating.

So only use appUrl when you already know the app is present:

  • You are inside your own mobile app and have checked with canOpenURL (iOS) or a package query (Android).
  • You are on a screen a user reached from the Kamee app.

The safe pattern​

Offer webUrl as the link, and appUrl as a secondary action:

<article>
  <a href={plan.webUrl}>
    {plan.coverUrl
      ? <img src={plan.coverUrl} alt="" />
      : <div className="placeholder" />}
    <h3>{plan.title}</h3>
  </a>
  {isMobile && (
    <a href={plan.appUrl}>Open in the Kamee app</a>
  )}
</article>

Note the coverUrl fallback — it is nullable, and a plan without a cover will otherwise render a broken image.

appUrl and webUrl both point at a plan's overview. There are no deep links to a specific week, day, or exercise, and the API does not expose a plan's contents — see Overview for the scope boundary.