Track an order
Customer App can show order progress and, for some orders, additional driver or map information. These are separate layers. No progress label, time estimate, marker, or map guarantees live, exact, complete, or current tracking.
An order can remain valid when a map or driver location is absent. Realtime connection status can be shown elsewhere in Customer App, but it is not a signal shown by the pinned Home progress or Order Details tracking surfaces. It does not prove freshness, and a moving marker does not prove the driver's exact current position or the order's final status.
Home progress and Order Details are different
| Surface | What it can show | What it does not prove |
|---|---|---|
| Home order progress | One selected order card with a status label, progress indicator, time estimate, and a path to Order Details | Continuous driver tracking, newest server state, or that the selected card represents every active order |
| Order Details status | The selected order's status, timing, progress, business, and available driver information | That every field changed at the same time or belongs to one complete realtime event |
| Order Details tracking map | Conditional driver, business, and customer markers for supported states | Exact location, uninterrupted updates, route accuracy, arrival, or provider availability |
| Reservation location | A conditional business-location image and an external directions handoff | Live driver tracking, reservation capacity, or successful directions handoff |
The Home card is a summary. Order Details is the owning surface for the selected order, but it still does not certify freshness or settlement.
Separate freshness from visibility
| Layer | Safe interpretation |
|---|---|
| Order read | A response for an authorized order at one point in time |
| Status or ETA | A derived label or estimate that can change and can disagree temporarily with other fields |
| Realtime connection signal elsewhere in Customer App | A channel connected at one point; the pinned Home progress and Order Details tracking surfaces do not show this signal, and missed events, room membership, and current data remain separate |
| Driver event | A location update associated with a driver identity; order, session, revision, age, and completeness still require validation |
| Animated marker | A visual transition between accepted points; animation can smooth, snap, or lag and is not a measurement of the driver's exact path |
| Map or image provider | A rendered representation from an external service; availability and displayed geography are provider-owned |
When layers disagree, treat tracking as unresolved until Order Details returns a reconciled current state; no single visible layer proves authority.
Internal and external drivers
| Driver class | Possible source | Important boundary |
|---|---|---|
| Internal driver | Current order data and driver-tracking events | Driver identity, order identity, account/project, event age, and revision must all match before an update is accepted. |
| External driver | Current order data and a separately identified external-driver event | External identity and data shape are distinct; internal-driver messaging and tracking assumptions must not be reused automatically. |
Either class can have no usable current location. A name, photo, phone control, or prior coordinate does not prove that current tracking is available.
Maps, directions, and contact are external boundaries
Displaying tracking can disclose precise driver, customer, or business coordinates and marker images to a map or image provider. A reservation map can also request an external map image, and a directions or phone control can hand off to another app.
Do not use documentation or troubleshooting to open directions, place a call, share a coordinate, or test a provider. Visibility of a control does not prove that the destination is approved, available, accurate, or completed.
Reconnect and cleanup
Order and driver updates can depend on realtime rooms, listeners, reconnect callbacks, timers, and the current account/project generation. A reconnect can rejoin or replay work, but it does not prove that:
- every required room is current and every old room was left;
- each listener exists exactly once;
- missed status or location events were recovered;
- a late event belongs to the current order, account, project, or driver; or
- a marker and the current order status are synchronized.
Logout, account change, project change, order change, leaving the screen, and replacing a socket generation must stop old tracking work before it can update the new context. The pinned paths do not establish that lifecycle completely.
States you may see
| Observable state | Safe interpretation |
|---|---|
| No Home progress card | No qualifying card is currently rendered; it does not prove that no order exists. |
| Progress card remains visible | The summary can retain earlier order data while a refresh or event is pending. |
| Order Details has no map | Status can still be available; driver/location/state/provider requirements may be unmet. |
| A marker appears or moves | The app rendered an accepted point or animation; exact current position is not certified. |
| A marker jumps | The visual can snap after a large or first usable change; it is not proof of the driver's traveled route. |
| Status and marker disagree | One layer may be stale, delayed, or incomplete; do not infer arrival or completion. |
| Map or image is unavailable | Provider rendering failed or was not eligible; order status remains a separate surface. |
| Driver class changes or details disappear | Stop using prior contact/location assumptions until the current order is reconciled. |
Troubleshooting safely
Home progress looks stale
Open the order only through trusted in-app navigation. Do not repeatedly reload or reuse a private order link to force an update.
Order status changes but the map does not
Treat location as unavailable or stale. Status and location settle separately; do not infer that either one corrected the other.
The marker moves unexpectedly
Do not record or share the coordinate. Report only the value-free state class; keep order, driver, customer, business, location, and time data out of screenshots and support notes.
Tracking disconnects and reconnects
Do not assume missed updates were replayed. Keep the current order unchanged and wait for the owning surface to present a supported status.
A map, directions, or phone control is unavailable
Treat the external handoff as unavailable and keep tracking state unknown.
Tracking changes after logout, account switch, or project change
Stop. Treat the update as stale until the current account, project, order, and driver context are re-established.
Accessibility and privacy
Progress, status, ETA, connection, driver, map-unavailable, stale, and unknown states need text and semantic status rather than color, motion, or map position alone. Controls need clear names and roles, predictable focus, and a safe return path. Large text must not hide status or recovery information, and reduced motion must have an equivalent nonanimated state.
Tracking alternatives must not require a customer to reveal or copy precise coordinates, driver/contact data, order identifiers, or provider details. This is the required verification posture, not a claim of current accessibility or privacy certification.
When to recertify
Repeat isolated review after changes to Home progress selection; order status or ETA derivation; internal/external driver models; location event identity, freshness, interpolation, room/listener/reconnect cleanup; account/project/order switching; dynamic/static maps, images, directions, phone or message controls; provider configuration; accessibility/reduced motion; or App/components/API authority pins.
Related guides: View active and past orders · Understand order details and status · Use the app offline and reconnect · Find Customer App help · Native integration boundaries