The person-grain TAM direction: given a topic_id, return the people
(as HEMs) who show intent on it, ordered by perc_score, strongest
first, with cursor pagination. Each HEM is a deterministic match key
(sha256 of a normalized email) you can intersect against your own
contacts; raw emails are never returned. count (the topic's total
people) is returned only on the first page.

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 becomes available the day after it is
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.