> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Track a live cascade by notify id

> Resolve a cascade or fan-out envelope by its notify id — see which channel each hop fired on, where it landed, per-hop and total billed cost, and whether it escalated past the primary hop.

# Track a live cascade by notify id

`POST /api/v1/notify` stamps every hop of a send with one shared notify id — through the Messages → **Multi-channel notify** composer or a direct API call alike. The [cascade (waterfall) guide](/guides/notify-cascade-failover) covers building and sending that chain; this guide covers resolving the whole envelope from that one id after you send, instead of opening each hop's message detail page individually.

## What the tracker answers

Paste a notify id and the **Track a cascade** panel resolves the envelope into one answer:

* **Which channel each hop fired on**, and where it landed (the destination address per hop).
* **Per-hop cost**, and the summed **total billed cost** across every hop attempted so far.
* An **Escalated past primary** flag when the cascade fired past its first hop.

That last flag is the quick read on whether the cheap first hop won the cascade or the chain burned fallback hops — the escalation behaviour you paid for.

## Where it lives

Open **Messages → Multi-channel notify** in the dashboard. The **Track a cascade** panel sits on the page below the composer card, next to the send form.

## Paste a notify id

The input takes the id minted in the send response (e.g. `notify_abc123…`) — or one copied from an API response body. The panel validates the shape before it fires a request: an id must start with `notify_` and contain only letters, digits, and underscores. A wrong shape (an empty field, a pasted URL, whitespace around the id) is rejected inline with "That doesn't look like a notify id — it should start with `notify_`", so a malformed paste never turns into a raw 404.

## The resolve call

The panel calls [`GET /api/v1/notify/:notifyId`](/api-reference/endpoints/messaging) — the unified cross-channel cascade receipt — with the id you pasted. One request returns the full hop chain, so you never poll the individual message ids. The response aggregates every hop into one receipt scoped to your tenant.

You can resolve a cascade while it is live: hops that have not settled yet show as **In flight**, and re-look-up the same id as the escalation advances.

## Reading the output

The panel renders the receipt's status stamp (one of **Delivered**, **Failed — every hop exhausted**, or **In progress — escalation list still armed**) and a summary strip with the hop count, the channel that delivered (when any), the escalated-past-primary flag, and the total billed cost. Below it, an ordered hop list shows for each hop:

* the **channel** (SMS, WhatsApp, email, and so on) and the **destination** it fired to;
* the hop's outcome — **Delivered**, **Failed** (with the human-readable reason), or **In flight** — with the timestamp;
* the **hop cost** in its billing currency, four decimal places.

The summed total in the strip is the cost of every hop attempted so far, so an escalated cascade shows exactly what the fallback chain actually spent.

## Not found

If the panel reports **No cascade matched that id**, the API returned `NOTIFY_NOT_FOUND` (404): no message stamped with this notify id exists in your tenant. That means one of two things:

1. **Check the id** — the notify id comes from the send response, not from a per-hop message id.
2. **Wait for the first hop to settle** — right after dispatch the first hop may still be between queued and a settled receipt; retry the lookup in a few seconds.

The full error contract is listed under [`NOTIFY_NOT_FOUND` in the error-codes reference](/reference/error-codes).

## Why it matters

Before this panel, the only way into a live cascade was to open each hop's own message detail page and re-assemble the waterfall yourself. Now the whole fan-out or waterfall envelope — the escalation order, per-hop destinations, and what the chain cost — resolves from the one notify id you already have.

## See also

* [Cascade (waterfall) fallback chains](/guides/notify-cascade-failover) — build and send the chain this tracker resolves.
* [/notify endpoint reference](/api-reference/endpoints/messaging) — full request/response specification for `POST` and `GET /notify`.