Skip to main content

​
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 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 — 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.

​
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