GET /v1/people/{id} — identified in a non-host listing role
on at least one episode. The guest endpoints are built around that Person
identity: every guest carries the same canonical handle used everywhere else on
the platform, so the speaker you find in a transcript, the person served by the
People API, and the guest in this directory are the same record. Resolve a guest
by slug (recommended — e.g. brad-gerstner) or by the encoded Person ID
returned as id.
A guest is someone who appeared on an episode in a listing role — distinct from
a mention, which is any line of dialogue where a person is
named, whether they’re in the room or not. Use Guests to follow who shows up; use
Mentions to follow who gets talked about.
What you can build
- Booking and PR research — find a guest’s complete appearance history, the shows they favor, and who else those shows book.
- Press-tour detection — surface people making the rounds right now with trends, the signal behind a book launch or product unveil.
- Brand-safety screening — read a guest’s suitability exposure across the shows they join before a sponsorship or partnership.
- Talent graphs — pivot from a podcast to its guest roster and back out to each guest’s wider footprint.
Choosing the right endpoint
The
{id} in every endpoint above is a Person reference (slug or encoded ID).
The exceptions are the two podcast-keyed views, GET /v1/podcasts/{id}/guests
and GET /v1/podcasts/{id}/recommendations/guests,
where {id} is a podcast reference (slug, Particle ID, or Apple/iTunes ID) —
they are the inverse views, listing the guests of a show and the guests a show
could book.
The guest directory
GET /v1/podcasts/guests returns a paginated directory of everyone who has
guested on the catalog, ranked by lifetime appearances by default.
Response
id, slug, name, and
image_url when a headshot is known) plus lifetime appearance_count and
distinct_podcasts. Pass any slug or id straight into the
profile endpoint to expand it.
Filters
A guest profile
GET /v1/podcasts/guests/{id} returns the lifetime profile: the full Person
payload — the same one served at /v1/people/{id} — plus a podcast-guest
activity block.
Response (truncated)
description, detailed_description, external_links, and —
when a company affiliation is known — current_role and roles) carry the
guest’s identity. knowledge_graph_entity is an optional secondary identifier —
a knowledge graph entity cross-reference attached to
some people — not the Person itself; rely on id/slug to identify a guest. The
stats block is the guest-specific part:
appearances_by_biasbuckets appearances by the political-bias rating of the host show. Keys includeNOT_POLITICAL(the dominant bucket for most guests, since most shows aren’t political) alongsideEXTREME_LEFT … EXTREME_RIGHT, so the political mix is contextualized. Counts sum to at mostappearance_count— appearances on shows whose bias hasn’t been evaluated are omitted.appearances_by_suitability_tierdoes the same for the IAB Tech Lab brand-suitability tier (SAFE,LIMITED,SENSITIVE,UNSAFE).top_podcastsis the (up to five) most-frequent shows, each with the guest’s per-show appearance count and the show’ssuitability_tierandbias.
Appearances
GET /v1/podcasts/guests/{id}/appearances lists the episodes a guest appeared
on, most recent first.
Response (truncated)
episode with the podcast that published it, the guest’s
identified speaking_seconds on that episode, and the show’s suitability_tier
and bias.
Filters
Podcasts a guest has joined
GET /v1/podcasts/guests/{id}/podcasts returns the distinct set of shows a guest
has appeared on, with a per-show rollup.
Response (truncated)
top_podcasts on the profile, but unbounded and
paginated — every show, not just the top five.
Guest roster for a podcast
GET /v1/podcasts/{id}/guests is the inverse pivot: the identified guests of a
given show. Here {id} is a podcast reference.
Response (truncated)
appearance_count is scoped to this show (Brad Gerstner’s 19 appearances on
All-In), while distinct_podcasts stays his lifetime count across the catalog.
Returns 404 when the podcast can’t be resolved.
Trending guests
GET /v1/podcasts/guests/trends surfaces guests who are currently making the
rounds — the cross-show interview activity that signals a book launch, product
unveil, news-cycle moment, or new-on-the-scene debut.
Response (truncated)
guest carries lifetime stats; recent_appearances is the count inside the
window. Every in-window appearance is on a distinct show — guests with repeats
on the same show inside the window are excluded — so the number doubles as
“distinct podcasts this window.”
This is not a leaderboard of perennial regulars. Recurring co-hosts and daily
news-segment contributors are filtered out by design: a guest must show activity
materially elevated above their own baseline, across multiple distinct shows,
with substantive (5+ minute) interviews. For a steady-state directory, use
GET /v1/podcasts/guests instead.Filters
Brand-suitability exposure
GET /v1/podcasts/guests/{id}/suitability returns the distribution of IAB Tech
Lab brand-suitability tiers across the shows a guest has appeared on, plus the
categories most often flagged in those shows.
Response (truncated)
lifetime and a trailing recent_90d window are returned; each buckets
the guest’s appearances by tier with episode and distinct-podcast counts.
top_categories lists the most-flagged IAB categories with their prevalence
(INCIDENTAL, OCCASIONAL, FREQUENT, PERVASIVE) and dominant treatment.
Recommended podcasts for a guest
GET /v1/podcasts/guests/{id}/recommendations/podcasts returns shows the person has
not appeared on, ranked by how related they are to the shows the person has
appeared on. It is the pitch list: where could this person plausibly go next, and
which of their past venues make the case.
Each recommendation is derived from the precomputed related set of the person’s own
shows (see Related Podcasts) and carries a score in (0, 1), a
band (strong, moderate, weak), and with include=via the person’s shows that
led to it. Circuit regulars are discounted upstream, so the list reflects fit rather
than fame.
Response (truncated)
A person with no identified appearances, or whose shows have no computed related set
yet, gets
200 with an empty data array. The shows a person has already been on are
at GET /v1/podcasts/guests/{id}/podcasts.
Recommended guests for a podcast
GET /v1/podcasts/{id}/recommendations/guests returns people who have guested on the
show’s related shows but never on this one, ranked by how related those venues are
and how established the person is on them. It is a booking pipeline, not a
prediction: the right reading is “guests your peer shows book that you have not.”
The podcast detail embeds the first five with include=recommended_guests on
GET /v1/podcasts/{id}.
Guests who appear everywhere (the podcast circuit’s regulars) are excluded, since
recommending them says nothing about this show. Each row carries the person, a
score and band, shared_show_count (how many related shows booked them), and with
include=via which shows.
Response (truncated)
A show whose related set has not been computed yet gets
200 with an empty data
array. The show’s existing roster is at GET /v1/podcasts/{id}/guests.
Pagination
The list endpoints use the standard envelope:limit (1–100, default 25) plus an
opaque cursor, returning { data, has_more, cursor }. Pass the cursor from
one response back as ?cursor=… to fetch the next page. The single-item
endpoints — the profile and the suitability exposure — are not paginated.
Related
- Mentions — every line where a person or company is named, host or guest.
- Brand Suitability — the per-show assessment behind a guest’s exposure profile.
- Episodes — episode discovery, including
entity_idrecall by speaker. - Knowledge graph entities — the optional
knowledge_graph_entitycross-reference attached to some guests.