---
title: "Invalid and unavailable app links"
description: "Understand the limits of app-link behavior when a link is unsupported or unavailable."
canonical: https://docs.ordering.co/docs/products/customer-app/app-behavior/invalid-links/
---

# Invalid and unavailable app links

An app link can be 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.

> **Current fallback boundary**
>
> This guide does not establish a Page Not Found screen as part of the customer navigation flow. It 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                                                    |
| ------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------- |
| 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 a supported 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.co 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.

## Boundaries for a safe fallback

An unavailable-link fallback is safe only when it is inert. It should:

- be registered in a navigation flow with a safe return path;
- show only a generic rejected state, 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 fallback does not establish these registered-route, safe-return, lifecycle, or runtime boundaries.

## 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 original 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 unknown fallback boundary. Stop processing the link rather than assuming it was ignored safely.

## Accessibility and privacy

An unavailable-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.

---

**Related guides:** [Customer App overview](https://docs.ordering.co/docs/products/customer-app/) · [Customer routing behavior](https://docs.ordering.co/docs/products/customer-app/app-behavior/routing/) · [Use the app offline and reconnect](https://docs.ordering.co/docs/products/customer-app/app-behavior/offline-reconnect/) · [Startup, connection, and update states](https://docs.ordering.co/docs/products/customer-app/app-behavior/startup-updates/) · [Platform and accessibility considerations](https://docs.ordering.co/docs/products/customer-app/app-behavior/platform-accessibility/)
