The person-grain TAM direction: given a topic_id, return the people who show intent on it, ordered by perc_score, strongest first, with cursor pagination. Each row is one person, however many addresses we hold for them, and carries a person_id. Each hem is a deterministic match key (sha256 of a normalized email) you can intersect against your own contacts; it is the address that carried the person's strongest signal on the topic. Raw emails are never returned. count (the topic's total people) is returned only on the first page. Billed rows are persons.

Filtering by one of your audiences

Pass audience_id to restrict results to people in that audience, so one call returns the people matching your persona and showing intent on the topic, instead of the whole topic. A typical flow is to page these HEMs, deduplicate against HEMs you have already resolved, and call GET /api/v1/lookup only for the ones that are new to you.

Which audiences can be used. Filtering works on your persona and account audiences, once each is enabled for intent filtering. Ask your account team to enable one. It is usually available within about an hour of being enabled; until then, and for any audience that is not enabled, the request returns 404. An audience matching more than about 50 million people cannot be enabled.

Audience results are built ahead of time from your audience's members, so they behave like the unfiltered endpoint:

• Pages are full. Every page except the last holds page_size people, strongest intent first. The one exception: someone who opts out after that day's build is removed when the page is read, so a page can occasionally come back one short. Page until next_cursor is absent.
• count is exact as of that day's build: the number of people in your audience with intent on the topic, honoring min_score and min_perc_score. An audience with no overlap returns count: 0.
• Every member counts, however they rank. A member with intent on the topic is included even if many people outside your audience rank above them.

resolve is not supported with audience_id and returns 400; resolve the returned HEMs with GET /api/v1/lookup. resolve_linkedin works as usual.

Filtered responses also carry audience_as_of, the date of the audience membership snapshot. It is reported separately from as_of (the intent date) because the two are rebuilt on different schedules, so a filtered result is the intersection of two snapshots taken at different times.