What Link Expiry Is
Links feel permanent, but they are not. A link expires when it stops sending people where it was meant to. Sometimes that is the plan: a sign-in link that works for fifteen minutes, an invite that is valid for a week, a promotion that ends on Sunday. Sometimes it is an accident: a provider shuts down, a plan changes, a domain is not renewed, or a destination page is deleted.
Both kinds matter for mobile growth teams. Deliberate expiry protects users and keeps offers honest. Accidental expiry breaks links that are still out in the world, on printed packaging, in old emails, in creator bios and in referral messages people saved months ago.
When Expiry Is Useful
Security is the main reason to expire links on purpose. Password reset links, magic sign-in links and email verification links should be short-lived and single-use, so a forwarded or leaked link cannot be used later. The same goes for links that grant access, such as team invites, document shares or payment requests.
Offers are the second reason. A limited-time discount link should stop granting the discount when the offer ends. The link itself can keep working, but the destination should change to explain that the offer has ended and suggest something current. That is usually better than a hard failure, because the click still has value.
Time-bound campaigns, such as event check-ins or flash sales, are the third. Expiring their links prevents confusion months later.
When Expiry Breaks Things
Accidental expiry is the costly kind. The clearest recent example is Firebase Dynamic Links. Google shut the service down on 25 August 2025, and links on its domains stopped resolving. Apps with millions of links in circulation had to migrate them before the deadline, and any link that was not migrated now fails. Stratzy migrated 1.23 million Firebase Dynamic Links when it moved its links to Linkrunner.
Plan changes can have the same effect. AppsFlyer announced that Zero plan accounts that did not upgrade by 15 September 2026 would lose advanced deep linking features, and that their branded domains and user invite links would be revoked, which may result in inactive links. Any time a link depends on a provider's domain or plan, its lifetime depends on that provider's decisions.
Domains are the third risk. A lapsed domain renewal, a deleted DNS record or an expired TLS certificate breaks every link on that domain at once.
Designing for Expiry
Separate the link from the offer. Keep the link itself long-lived and change what it points to as offers start and end. Give every link an explicit fallback, so an ended offer lands on a useful page rather than an error.
Own the domain. Links on a domain or subdomain you control can be moved to a new provider by changing where the domain points, without reprinting or resending anything. Links on a provider's shared domain cannot.
Keep an inventory. Know which links are printed on packaging, posted in bios, embedded in old emails or saved in referral messages, because those are the ones you cannot recall.
Monitoring and Migrating Links
Check link health regularly. A simple script that requests your most important links and checks the response code and destination catches broken links before users report them. Test a sample on real devices too, because routing failures do not always show up as error codes.
When a provider change is coming, start early. Export your links and their parameters, recreate them with equivalent routing and fallbacks, update the apple-app-site-association and assetlinks.json files for your domains, and redirect old links you control. The Firebase Dynamic Links migration guide walks through this for FDL. Linkrunner links run on branded subdomains, with Linkrunner hosting the verification files, so your links stay on a domain you own. See deep linking.