On this page
A user lands on your signup page from a link in someone's TikTok or Instagram bio, types their email, and hits "send me a magic link." Your backend does everything right — generates the token, emails it, waits. The user opens their mail app, taps the link, and your product opens to a page that says "this link has expired or is invalid," or just dumps them back at a logged-out login screen. They tried to log in. You told them to check their email. They checked their email. And they're still not logged in.
This isn't a bug in your token logic, and it isn't a content problem. It's a browser-context mismatch you can't see from your own dashboard — it shows up as a quietly low magic-link completion rate, a support ticket queue full of "the link doesn't work," and a signup funnel that leaks at the one step you thought was the simplest.
the conversion problem magic-link products face
Magic-link auth depends on a closed loop: the same browser that requested the link must be the browser that opens it. The request sets a cookie (or a stored verifier, or a server-side session keyed to that browser's request). The emailed link carries a token that, when opened, gets matched against that pending session and exchanges it for a real one. The whole flow assumes "the browser that asked" and "the browser that opens the link" are the same browser.
They are not the same browser when the user started inside an in-app browser. When a user taps your link from inside TikTok, Instagram, or any platform webview, the request for the magic link happens inside that webview, with that webview's isolated cookie jar. Then they switch to their mail app, tap the link, and the OS hands the link to their default system browser — Safari or Chrome — which has a completely separate, empty cookie jar. The token arrives in a browser that has no pending session to match it against. So you exchange the token for nothing, or you bind a session to a browser the user immediately abandons, and the user bounces back to the webview still logged out. The loop never closes.
We named this problem the vanishing visitor and wrote the full mechanism explainer there. The short version for magic-link products: the pending-auth state lives in the browser that requested the link. The platform webview is its own browser. The mail-app handoff routes the token to a third browser. Three cookie jars, one token, no match — the user does everything right and still can't get in.
what this costs
Magic-link completion is something you can actually measure, unlike most of these losses — count "links requested" against "links successfully exchanged," then segment by traffic source. Products that do this find the gap is brutal on in-app-browser-sourced traffic specifically: completion on webview-originated requests routinely lands well below the rate on requests that started in a real browser, because the loop physically can't close.
The honest framing is a range, not a fixed number: it depends on how much of your top-of-funnel arrives via social bios versus search or direct, and on whether your link's first hop is already a webview. But the structural cost is the same shape every time — you pay full acquisition cost to get the user to the email step, and then lose them at token exchange for a reason that has nothing to do with your product. Worse than a normal funnel leak, because these are users who explicitly asked to log in. The intent was maximal; the mechanism failed.
what linkboo does
linkboo replaces the URL you put in your social bios, ad destinations, or QR codes with a link-in-bio page (or a direct-route link — your choice) that runs an in-app browser escape on every outbound click. When a user taps your linkboo URL from any webview, linkboo detects the in-app browser and bounces the destination out to the user's real system browser — Safari on iOS, Chrome on Android — before your signup page loads. So the magic-link request happens in the same browser that will later open the link.
The user never sees a friction prompt and never has to know what "open in Safari" means. By the time they type their email, they're already in the browser that the mail-app handoff will route the token back to. Same cookie jar on both ends. The loop closes.
Concretely, for magic-link products this means:
- The request browser and the open browser become the same browser — the pending-auth session and the token land in one cookie jar, so the exchange succeeds the first time
- Your token logic stops getting blamed for a routing problem — no changes to your auth code; you fix the context, not the cryptography
- Returning users with a live session aren't forced to re-auth — they land in the browser where their session already lives
- Fallback is graceful — if something can't escape, the link still lands in the real browser, not the cookieless webview, so the loop has its best chance
linkboo is also a full link-in-bio page — multiple links, themes, a profile, the things you'd expect from a Linktree or Beacons alternative. The escape flow is the wedge.
the destinations where magic-link products bleed the most
The deep mechanism writeup for the magic-link failure mode:
- Magic-link login in an in-app browser — why the request-browser / open-browser split breaks the session loop, what the OS mail handoff actually does to your token, and how the escape keeps both ends in one cookie jar
If your onboarding also leans on OAuth round-trips or passkeys, the same browser-context split bites those flows too, and linkboo's escape applies identically. The full destination index is here.
why not Linktree, Beacons, or a plain redirect?
None of them run an in-app browser escape. They're link-in-bio pages and dumb redirects. When a user taps a Linktree URL from inside TikTok, your signup page opens inside TikTok's webview exactly as a raw URL would — the magic-link request still gets bound to the webview's cookie jar, and the token the user opens later still lands somewhere else. A naked 301 to your signup page does nothing for this; the redirect resolves inside the webview, so the context mismatch is unchanged. The structural loss is identical with or without their page in the middle.
If you're comparison-shopping the broader category, linkboo vs Linktree is the closest mainstream comparison.
pricing
Free up to a real volume of monthly clicks. No per-click pricing — which matters when the link is a top-of-funnel acquisition surface, not a revenue event in itself. The escape flow works on the free tier; it closes the magic-link loop exactly as well as the paid tier does. See plans.
adjacent pages
- /for/passkey-products — passkey and WebAuthn flows that break on the same request-browser split
- /for/oauth-developers — OAuth redirect round-trips that lose state at the webview handoff
- /for/saas-founders — SaaS top-of-funnel signup leaking at the in-app browser
- /for/ios-product-teams — universal-link and webview behavior on iOS specifically
- /for/stripe-merchants — checkout and saved-card sessions exposed to the same cookie-jar problem
Your user typed their email and asked to log in. Don't let the webview be the reason the link they opened couldn't find the session that requested it.