Use a password to control access through your AppRoute link, an expiry date to stop it at a chosen time, and a click cap to limit its traffic. Password protection requires Pro or Team; expiry and click caps are also listed as Pro and Team features in the current plan details. Choose the setting that matches your reason for restricting the link. A password protects the path through the short URL; it doesn't make a public app listing private or replace authorization inside your app.
01 What does each control actually restrict?
| Your reason for restricting the link | Control to choose | Boundary to keep in mind |
|---|---|---|
| Ask visitors for a password before they continue | Password | Someone with the public destination URL can still visit it directly. |
| Stop the link after a deadline | Expiry date | The deadline stops access through this link; it doesn't remove the destination. |
| Stop the link when its recorded click count reaches a limit | Click cap | The cap controls link traffic, not installs, purchases or a fixed number of people. |
A click cap also differs from your account's monthly tracked-click allowance. You set the cap on an individual link to limit its traffic. Don't use it to allocate a limited number of licenses or claim spots for the first people who click: a click isn't proof of a unique visitor, an install or a purchase.
02 What happens when settings overlap?
AppRoute checks expiry and the click cap before it checks the password or chooses a destination. For a link with all three controls, the order is:
- Check whether the link is inactive. If the expiry time has arrived or the recorded click count has reached the cap, visitors see a “This link is no longer active” page explaining that it expired or reached its click limit.
- Check password access. An active link asks for its password unless the browser has a valid unlock cookie from an earlier visit.
- Choose the destination. Once the visitor passes the applicable controls, AppRoute chooses where to send them.
For example, suppose you set a password, a Friday deadline and a cap of 200 clicks. If the link reaches 200 recorded clicks on Thursday, it becomes inactive before the deadline. If Friday's deadline arrives first, unused clicks don't keep it open.
Record the deadline's time zone alongside your settings: the expiry input uses your browser's local time. When changing a blocked link, inspect every control. Clearing the click cap won't reopen an expired link, and removing the deadline won't bypass its password. Use a fresh private browser to check the password prompt, since an already unlocked browser may skip it.
03 What should I test before sharing?
Test fresh and unlocked browser paths, active and blocked states, and keep a settings record. Use a separate test link so your checks don't consume the real campaign's click cap. The worksheet below is a suggested procedure, not a record of tests we've run.
| Check on the test link | Expected result |
|---|---|
| Enter an incorrect password in a fresh private browser. | The password gate keeps the destination behind the prompt. |
| Enter the correct password while the link is active. | The link allows access to its destination. |
| Reopen the link in the unlocked browser. | A valid unlock cookie can let you through without another prompt. |
| Set a future expiry, then change it to a past time. | An otherwise active link stays open before the future deadline; the past deadline produces the inactive-link page. |
| Set a small click cap, then open the test link until its recorded count reaches that cap. | Once its recorded count reaches the cap, the link becomes inactive. |
| Combine a password with an expired or capped state. | The inactive-link page appears before the password prompt. |
Record the deadline and time zone, cap, and whether password protection is enabled.
Before sharing, compare the campaign link's saved controls and destination URLs with your record. Then use the routing checks on your test link to confirm where each device lands.