One link, every store

Yes, and that includes the parts these services normally charge for: Mac and Windows destinations, your own short name, campaign parameter forwarding, a logo in the QR code, the country and referrer breakdowns, and as many links as you need. There's no plan to upgrade to, no trial clock and no watermark.

Yes, that's what the deep link field is for. Paste your app's own scheme — myapp://product/42 — or an https address your app claims as a universal link, and anyone who already has the app lands inside it. Anyone who doesn't still gets the store, so it never costs you an install. On Android this is a single URL the system understands and it just works. On iPhone it's a page with one button, because Apple gives a web page no way to open an app from inside Instagram's browser without a tap. That tap is the honest version of this feature — anything claiming otherwise is either not working from Instagram or is about to send half your visitors nowhere.

On Android, yes, properly: the link hands the visitor to whichever browser they've set as default. On iPhone, no — and nobody else can either. iOS gives a web page no API to open Safari, so what this does instead is tell the visitor which two taps to use, name the app they're stuck in, and point out Instagram's own setting for making it permanent. We'd rather show you that than pretend there's a trick. If you've seen a service claim it escapes iOS in-app browsers, it either doesn't, or it's leaving people on a page that silently does nothing.

Usually sign-in. Google refuses OAuth from embedded webviews outright, so a “Sign in with Google” button inside Instagram's browser just errors. Saved passwords, passkeys, Apple Pay and extensions are all missing there too. If your destination is a plain page it's mostly fine, which is why this is off by default.

A scheme — myapp:// — is registered by your app and always launches it from inside a webview, but does nothing at all when the app isn't installed, so the link needs a store address behind it and a moment to notice. A universal link is an ordinary https address your app claims, which iOS and Android route to the app instead of the browser, and which falls back to your website by itself. Universal links are nicer and need your app to publish an association file at a fixed path on your domain. Either works here.

Only for an https deep link, where it names the app to open so the link works whether or not your App Links are verified with Google. A custom scheme already says which app it means. Leave it blank if you're not sure — the link still works.

It reads the user-agent the browser sends with the request — the same string every site uses to tell a phone from a laptop. An iPhone or iPad goes to your App Store link, Android to Google Play, a Mac or Windows machine to its own store if you set one, and anything else to your fallback.

It does, since iPadOS 13. We use the client hint the browser sends alongside the user-agent, which still says mobile, so an iPad lands on the App Store rather than the Mac App Store. When you haven't set a Mac destination the distinction doesn't matter anyway, because both fall through to your iOS link.

Only the fallback. Everything else is optional and falls through in a sensible order: a Mac with no Mac destination gets your iOS link before it gets the website, and a Windows machine never gets sent to Google Play.

No. There's no trial that switches it off and no plan it can fall out of. You can set your own expiry date if you want one, and pause a link at any time from its dashboard.

Yes, that's the point of it. The printed code contains the short link, not the store address, so you can change every destination from the dashboard and the same code keeps working.

If you share the link as /l/yourapp?utm_source=poster, that parameter is copied onto the store URL, so your attribution survives the redirect instead of being dropped at the door. Parameters already on your store URL always win, and the Play package name is never overwritten.

A count, a device class, an operating system, a country, the site the click came from, the campaign name in the URL, and which of the four things the link did — tried your app, sent someone out of an in-app browser, showed the stop-off page, or went straight through. That's all. No IP address is stored, no cookie is set, and nothing here identifies an individual person.

No, and neither can anyone else without following people around. The phone doesn't report back, so the stats say the link tried your app rather than claiming it succeeded. What you can read off them is the shape of it: if your deep-link clicks are high and your store clicks stay flat, the people tapping already had the app.

Yes. Your dashboard link contains an edit key, and the same key reads the stats as JSON from /api/links/<id>/stats. No API plan and no key to provision.

No. When you create a link you get a dashboard address that contains its edit key, and that address is the only way back in — so save it somewhere. There's no account, which also means we can't email it to you if it's lost.

Instead of redirecting immediately it shows the app's icon, name and rating with a store button, then continues on its own. It's useful when people need to recognise the app before landing in a store, and it's off by default because a redirect is faster.