REST API
List a monitor's people
The people a monitor collected, newest first.
GET
/v1/monitors/:monitor_id/peopleParameters
monitor_idstringrequiredstate"seen" | "prefiltered_out" | "resolving" | "resolved" | "unresolvable"optionalsincestringoptionalISO date-time: people updated after it
whereobjectoptionalpersona predicate on the engager attributes (describe_monitors)
cursorstringoptionallimitintegeroptionaldefault 50 (min 1, max 500)
What your agent reads
The tool description exactly as an MCP client receives it in tools/list — it doubles as the full behaviour of the endpoint.
The people a monitor collected, newest first: state (seen → resolving → resolved | prefiltered_out | unresolvable), name, headline, and — once resolved — the structured title, seniority, function, company (domain when in our index), country, e-mail status, plus how they engaged. `where` = the same persona predicate as a subscription's trigger.where (over the resolved attributes). RECORD COST: a person on a monitor costs ONCE — 40 records for a commenter, 80 for a reactor — however you take them: the first time they are shown here or delivered by a subscription; afterwards they are free on every path (list again, deliver, people list). People not resolved (seen, resolving, prefiltered_out, unresolvable) are free and carry only name, headline, link and state. When the allowance cannot cover a page, the affordable prefix is returned with `withheld`. Page with cursor (≤ 500).
Over REST, parameters go in the query string.
Errors follow one format.