Get traffic by rep
Returns the traffic a store’s field of reps drove for a named reporting period — the leaderboard behind the Reps tab and the two traffic tiles above it.
A visit is credited to a rep by identity rather than by channel: it carries the rep’s attribution_member_id, or a share_id whose share belongs to them, or both. Where both are present and disagree, the stamped member wins. Identity has been recorded since long before the channel column existed, so this reaches back further than the channel-keyed figures on the Sources tab, and the two will not agree over a long window.
visitor_share and the ranked rows come from that one filter, so the tile and the leaderboard beneath it cannot disagree. Its denominator is every visitor the store saw over the requested window and is deliberately not narrowed to the first rep-driven visit: months before the field drove anything held no rep traffic, and dilution is the answer rather than a distortion.
Rows are ranked by distinct visitors descending, ties broken on the rep’s name, and cut to a top N. Because one visitor can be sent by two reps, the rows’ visitors need not sum to total_visitors and must not be rendered as a share of a whole. Reps the merchant hid from leaderboards are omitted from the rows while their traffic still counts toward active_reps and visitor_share, and a rep whose member record has since been deleted still ranks and is still named.
Each row also names the resource that drew the most of that rep’s traffic, or null when none did. That column is read from the per-resource rollups rather than from the events, so it answers only for traffic that landed on a tracked resource — about half of rep traffic, and a different half per store. A null there is a rep whose traffic never touched one, not a gap in their numbers.
unattributed is not a rep. It folds the rep-classified traffic that names nobody — an admin-owned share has no member — so the rows plus the remainder reconcile with visitor_share. It carries no member_id and no name, and is served beside the rows rather than among them.
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
The traffic a store's field of reps drove over a period — the resolved window, how many reps were active, the field's share of every visitor, the ranked leaderboard, and the remainder that names nobody, wrapped in the standard API response envelope.
How many reps drove traffic, with the comparison every other headline figure carries.
Distinct visitors who arrived on a rep-carrying visit over every distinct visitor in the window, rounded to four decimals, and 0 when the store saw none. Computed from the same identity filter as the rows, and its denominator is not narrowed to the first rep-driven visit.
0 <= x <= 1Revenue from every order this store's field drove over the window, as a decimal string in the platform's base currency (the sum of each order's amount_in_base), rounded once to the base currency's minor units.
A string rather than a number so no precision is lost in JSON. A client must not parse it into a display path that rounds it a second time.
Summed from the same stamped rows as the reps[].revenue column
beneath it, so the two are one measurement rather than two. It is not
the conversion figure the Sources tab serves for channel = 'reps',
which is keyed on a column three years younger than rep identity and
would disagree with the leaderboard.
It counts every rep credited in the window, including reps below the rank cut and reps the merchant has hidden from leaderboards, so the served rows do not add up to it — the same rule visitor_share and active_reps follow. It is not the store's whole revenue either: an order no rep drove is counted here in no row at all.
This is traffic credit, not commission credit. It answers "whose link brought the shopper who bought", which is a different question from the rep a sale is credited to at checkout, so it will not reconcile with the order's own attribution or with commission reporting, and neither figure is a check on the other.
The day this store's rep revenue starts covering (YYYY-MM-DD, UTC), or null when no order has ever been credited to a rep here.
Read every money figure on this card against it. Rep credit is
recorded forward only and was never backfilled, so the money columns
have a far shorter history than the visitor columns beside them on
the very same row, and a window can sit entirely before this date —
in which case orders are 0 and revenue is the currency's zero string
for an era that was simply never measured. $0 over a twelve-month
window means "the field earned nothing" only when this date precedes
the window; otherwise it means "we started measuring recently", and
in this tab's first months that is the more common reading. Surface
it wherever the money is shown.
Null therefore means "no rep-credited order exists yet", not "unknown" and not "covers the whole window".
It can never precede 2026-07-22 under any circumstance, because an order is only credited from a visit carrying a resolved channel and no earlier visit carries one. In practice it is later still: it is the first rep-credited order this store recorded, so a store whose first orders after the feature shipped were all driven by nobody reports a slightly later day than recording actually began. It moves earlier only in that it settles at the true first credited order.
How many of the window's reps drove traffic for this store for the first time — they have a qualifying visit inside the window and none before it, back to the store's first recorded day.
Always an integer, never null. A zero is a real count meaning no rep started this period, so no not-measured state is needed for it.
It is scoped to this store: a rep with years of history under another company is new here, because this is the first traffic they drove here. And "qualifying" is deliberately not the same bar the rows use — a rep whose earlier traffic was all bots is new, because a bot is not traffic anybody drove, but a rep whose earlier traffic was merely cookieless is NOT new. visitor_uid began populating 2026-07-08, so requiring it on the lookback would report most of the field as newly activated and measure that column's rollout instead.
Measured like active_reps rather than like the list: it counts the resolved rep identity, so a rep hidden from leaderboards is counted when they start driving traffic, exactly as their traffic is counted in active_reps and visitor_share. It is therefore not a subset of total_reps, and on a store that hides reps it can exceed it.
Total distinct bot-free visitors over the window — the denominator visitor_share is taken against.
How many reps this leaderboard ranked before it cut to the rows in
reps, so a card serving a top N can state what it is not showing.
The endpoint serves neither a search nor a sort parameter, so a client filtering or re-ordering the rows it has is working over a prefix of this many reps, not over the field. Read "no reps match" against this number: it means "none in the top N", never "no such rep".
It counts the list rather than the field, which is the one place it parts company with active_reps.current. A rep the merchant has hidden from leaderboards, and a rep identity this store cannot name, are both measured in the tiles and appear on no page of this list, so neither is counted here. The unattributed remainder is not counted either — it is rep-classified traffic, not a rep. So total_reps is at most active_reps.current, and equal to it for a store that has hidden nobody.
Reps ranked by distinct visitors descending, ties broken on name, cut to a top N. Reps hidden from leaderboards are absent.
The rep-classified traffic that names nobody, folded into one remainder — chiefly visits arriving through an admin-owned share, which carries no member. It is not a rep row, and carries neither a member_id nor a name.
The HTTP status code echoed in the response envelope.