Invalid and unavailable app links
An app link can be intended for another app or project, unknown, malformed, incomplete, unavailable in the current context, or unauthorized for the current customer. A link result is not evidence that its target exists or that an earlier app action completed.
The pinned Customer App source contains a Page Not Found screen, but that screen is not registered in the current navigator graph. It is orphan source, not proven customer behavior. This guide does not promise that an invalid link opens that screen or any other fallback.
Distinguish the link states
| Link state | What it can mean | What it does not prove |
|---|---|---|
| Intended for another app or release | The operating system can decline delivery or choose another installed handler. | That Customer App received or rejected the link. |
| Unknown | The delivered link does not match an accepted route class. | That a Page Not Found screen appears. |
| Malformed | The link cannot be interpreted as one complete typed request. | That it is harmless or that no previous action settled. |
| Incomplete | A recognized route class lacks the context required by its destination. | That guessing or adding a value is safe. |
| Recognized but unavailable | The route can be known while its business, cart, order, feature, or current context is unavailable. | That the link is syntactically invalid. |
| Unauthorized | The current account, guest context, project, or session may not access the target. | Whether the target exists for another customer. |
| Gated | Sign-in, verification, profile completion, location, connectivity, or another prerequisite can appear before the target. | That the original target remains authorized after the gate changes state. |
| Offline or service unavailable | The app, Ordering service, or another dependency cannot establish current target state. | That retrying the link or an earlier action is safe. |
| Expired, duplicate, or replayed | The link belongs to an earlier time, account, project, session, or navigation attempt. | That it can be reused without another authorization check. |
Do not reveal whether a target exists
Invalid, missing, and unauthorized results should use the same safe public language when revealing a difference could expose another customer's business, cart, order, message, account, payment, or location context.
Do not diagnose a link by changing its values, substituting another reference, guessing a destination, or repeatedly opening it. A resource reference is not an access grant.
Requirements for a safe fallback
A future accepted fallback must be inert. Before it can be documented as current behavior, it must:
- be registered in one intentional navigator with a valid return owner;
- receive only a rejected state class, never private link values;
- perform no business, product, cart, order, payment, provider, account, notification, location, or external-content read or mutation;
- show one generic message without resource-existence differences;
- expose one named safe-return action with deterministic signed-in, signed-out, guest, project, and platform behavior;
- clear the rejected intent before returning so it cannot replay; and
- provide accessible heading, focus, button semantics, large-text layout, and screen-reader announcement on iOS and Android.
The current orphan Page Not Found source does not satisfy the registered-route, nested-return, lifecycle, or runtime evidence required by this contract.
Keep lifecycle state current
Cold launch, foreground open, background return, duplicate delivery, and an already-running app can process navigation at different times. An invalid or unavailable result must remain bound to the app, project, account, session, and attempt that received it.
If the customer signs in, signs out, changes account or project, completes a gate, or the app restarts, discard the prior rejected intent. Do not replay it unless the current session authorizes a new attempt.
Safe return and unknown outcomes
Returning to visible in-app navigation is separate from retrying the link. If a link reached checkout, an order, a payment handoff, an account change, or another consequential destination before failing, keep that outcome unknown until the owning Customer App screen shows current authorized state.
Do not use browser Back, app restart, reconnection, or the same link again as proof that the earlier action failed or was cancelled.
Troubleshooting
Customer App does not open
The operating system might not have delivered the link to this build. Open the installed Customer App normally; do not edit or redistribute the unknown link.
Customer App opens somewhere unexpected
Startup, account, project, permission, or navigation state can supersede the intended destination. Use only the current trusted in-app navigation and keep the link result unverified.
A sign-in or account prerequisite appears
The target remains gated. Completing a prerequisite does not automatically reauthorize the old link. Return through the app's current navigation instead of reopening it.
A business, checkout, or order state is unavailable
The route might be recognized while its resource is missing, inaccessible, or stale. Do not substitute another reference. Check only the current business, cart, or Orders surface that the app makes available to this customer.
The app is offline or reports an error
Treat prior information as stale. Do not repeatedly open the link or repeat an effectful action. Reconnection does not settle the earlier result.
No error or fallback appears
That is within the current unverified fallback boundary. Stop processing the link rather than assuming it was ignored safely.
Accessibility and privacy
An accepted rejected-link state needs a clear heading, concise generic message, one named safe-return action, predictable focus, and no color-, animation-, or gesture-only meaning. Do not share full links, screenshots containing account or order information, resource references, provider data, or private error details when asking for help.
When this guidance needs revalidation
Repeat the invalid-link review when supported link classes, native app-link registration, parser validation, startup/account/project gates, destination authorization, fallback navigation, safe-return behavior, offline/restart handling, error wording, or accessibility changes.
Related guides: Customer App overview · Customer routing behavior · Use the app offline and reconnect · Startup, connection, and update states · Platform and accessibility considerations