Get traffic flows
Returns which acquisition channel sent traffic to which piece of content, for a named reporting period — the Sankey behind the Sources tab’s flow card.
The payload carries the resolved period window, the days of it the channel rollups could answer, one ribbon per (channel, destination) pair with its bot-free visits, and the two counts a client states coverage from. Ribbon values are visits, not distinct visitors.
Destinations are ranked and cut server-side. Each channel with folded traffic carries one remainder ribbon — resource null, other true — whose visits are the exact tail it replaced, so the ribbons always sum to accounted_visits. folded_destinations counts the distinct destinations the fold replaced, and is zero when nothing was folded.
covered_window is null for a period lying entirely before the channel rollups began, which is distinct from a covered window with no flows in it. capture_start reports when the rollups began either way, so an empty period reads as an empty period rather than as an absence of traffic.
stamped_visits is gross while the ribbons are bot-free, so the coverage ratio under-claims and never over-claims.
Authorizations
Bearer token authentication
Query Parameters
Named reporting period (default last_30_days). Supported names: today, last_7_days, last_30_days, last_90_days, last_12_months, this_month, last_month. An unsupported name returns 422.
Response
Success
Store-traffic flows for a period — the resolved window, the days of it the channel rollups could answer, the ranked channel-to-content ribbons with their folded remainder, and the two counts a client states coverage from, wrapped in the standard API response envelope.
The days of the requested period the flows could be drawn over — the requested window intersected with the days this store's channel rollups have carried rows. Every count in the payload is taken over this window rather than the requested one, the coverage denominator included.
Null when the two do not meet, which means the period lies entirely before the channel rollups began. Null arrives with empty flows and zeroed counts, and is deliberately distinct from a covered window whose flows are empty — that means the days were answerable and nothing was visited. Do not coerce one into the other.
The day this store's channel rollups first carried a row (YYYY-MM-DD, UTC), or null when they never have. Reported whether or not the requested period overlaps it, so a client can say when the flows begin rather than presenting an empty period as an absence of traffic.
A null covered_window with a capture_start set is a period that ends before capture; a null covered_window with a null capture_start is a store that has never had a rollup row at all.
One ribbon per (channel, destination) pair with visits over the covered window, ranked destinations only. Channels with no traffic in the window are absent rather than zero-filled.
Destinations are cut to a bounded ranked set server-side, and each channel with folded traffic carries one remainder ribbon — resource null, other true — so the ribbons still sum to accounted_visits.
How many distinct destinations the fold replaced across every channel, counting a destination reached by three channels once. Zero when nothing was folded, in which case no ribbon carries other.
The sum of the visits on the ribbons this payload carries, the folded remainder included, so a merchant adding the diagram up arrives at this number.
Channel-stamped visits over the same covered window, read from the store's channel rollup — the traffic there was, against the accounted_visits the diagram draws.
Gross, bots included, while every ribbon is bot-free. So accounted_visits over stamped_visits is bot-free over gross and under-claims coverage: the real share of nameable traffic is at least what this payload implies, never less. Two checkable numbers rather than one computed percentage, so the client owns the phrasing.
The HTTP status code echoed in the response envelope.