Notification and app navigation behavior
Customer App can receive a notification or app-link request for a customer screen. The request is not authorization and does not guarantee a destination. Current behavior is source-only for this documentation wave.
Recognized destination families
Pinned source recognizes these broad families without establishing that every request is supported or safe:
| Destination family | Intended customer context | Important boundary |
|---|---|---|
| Current customer entry | The available Home or signed-in customer journey | The app can still require tutorial, login, verification, profile, project, connection, or other startup gates. |
| Business or product | One available business or product-detail context | A product destination must open an inert detail state; it must not add or update a cart merely because a request arrived. |
| Checkout | An already authorized current cart review | A cart reference is not a capability and does not prove checkout readiness, payment state, or ownership. |
| Order detail | An already authorized current order | An order reference is not a capability and does not prove that the current account can read the order. |
The current live notification handling establishes an order-oriented request only. A cart-notification destination is not established by the pinned path and must not be promised.
Required routing firewall
A future accepted implementation must complete every gate before mounting a destination:
- Source and provenance: accept only the approved delivery channel and app context. A custom app link does not provide verified origin by itself.
- Typed parsing: accept one known destination family and only its bounded, expected value classes. Reject unknown or ambiguous input.
- Freshness and one-time use: expire and consume sensitive intents once; reject duplicate, delayed, or replayed delivery.
- Project and session binding: require the same current project, account, session, and app lifecycle that the intent was issued for.
- Authorization: verify the exact business, cart, order, or other resource through Ordering without revealing whether a foreign resource exists.
- Readiness: wait for current navigation and startup gates without keeping stale intent state after logout or a project/account change.
- Effect firewall: mount a pre-action destination first. Do not add a product, confirm a cart, open a provider, mark a message read, or trigger another consequential action automatically.
The current pinned paths do not establish this complete firewall.
Cold, warm, and foreground delivery
| App lifecycle | Safe required behavior | What is not established now |
|---|---|---|
| Cold start | Hold one sanitized intent until the current app, project, session, and navigation are ready; then authorize and consume it once. | Guaranteed delivery, destination, fallback, or cleanup. |
| Warm app | Preserve the current safe journey until the new intent passes every gate. | That a new request cannot replace or mix with current work. |
| Foreground callback | Bind the callback to the current lifecycle and discard late or duplicate results. | That provider or notification handlers are removed and registered exactly once. |
| Logout, account change, or project change | Remove every pending intent and re-authorize any later request from the beginning. | Cross-session or cross-project cleanup. |
Effect-capable destinations and unknown outcomes
Opening a screen can start reads, listeners, timers, external media, or provider preparation. Checkout, order, product, message, and support destinations can also contain actions that change customer state.
If an intent opens a screen but its resource, provider, or earlier action has no authoritative result, keep the outcome unknown. Do not infer success from navigation, and do not repeat an effect to force a visible result.
Troubleshooting safely
Nothing happens
Return to the current app journey. Do not repeatedly open or share the request. Cold-start readiness, unsupported input, or a blocked destination can produce different results.
The app opens an unexpected screen
Stop before acting. Use the current visible navigation to return safely; do not enter a private value or follow an external destination to correct the route.
Login, verification, profile, or project state appears
Treat it as a separate gate. Completing a gate must not automatically replay an old intent without fresh authorization.
A business, cart, or order is unavailable
Do not test other references or infer whether the resource exists. Continue only through the customer journey already available to the current account.
A cart notification was expected
The current pinned notification path does not establish cart routing. Do not recreate the behavior with a private link or notification value.
The destination appears after account or project change
Treat it as stale. Do not use the screen until the current journey is restored and the resource is re-authorized.
Accessibility and fallback
An unavailable or rejected request needs a local, inert state with a readable heading, a concise explanation, and one named safe-return action. Focus should move to that state and return predictably without reopening the request. The fallback must not echo private values, load remote media, or depend on color, animation, or vibration alone.
Important limits
Notification delivery is not guaranteed and must not replace current authorized in-app status. Its timing and destination are not guaranteed, and an app link is not a substitute for the normal ordering flow. This guide does not ask you to enable notifications, change a device permission, open a link, or share notification content. It also does not publish a scheme, host, route format, identifier, payload, or test procedure.
When to recertify
Repeat the routing review after changes to App, shared-components, Ordering API or release pins; native link declarations; notification/provider handlers; destination families or values; authentication/project/session gates; startup/navigation readiness; product/cart/order/message/support side effects; offline/restart behavior; fallback/accessibility; or intent freshness, one-time-use, logging, redaction, and cleanup.
For related boundaries, see Invalid and unavailable app links, Use the app offline and reconnect, App-link boundaries, Push-notification boundaries, and Customer App experience variants.