Skip to main content
A guest is a Person — Particle’s first-class entity for an individual, served in full at 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
Each row is a compact guest: the Person identity (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)
The Person fields (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_bias buckets appearances by the political-bias rating of the host show. Keys include NOT_POLITICAL (the dominant bucket for most guests, since most shows aren’t political) alongside EXTREME_LEFT … EXTREME_RIGHT, so the political mix is contextualized. Counts sum to at most appearance_count — appearances on shows whose bias hasn’t been evaluated are omitted.
  • appearances_by_suitability_tier does the same for the IAB Tech Lab brand-suitability tier (SAFE, LIMITED, SENSITIVE, UNSAFE).
  • top_podcasts is the (up to five) most-frequent shows, each with the guest’s per-show appearance count and the show’s suitability_tier and bias.
A guest profile returns 404 when the Person exists but has never appeared as a guest, so a 200 is itself confirmation of guest activity.

Appearances

GET /v1/podcasts/guests/{id}/appearances lists the episodes a guest appeared on, most recent first.
Response (truncated)
Each row pairs the 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)
This is the aggregate behind 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)
The rows are the same compact guest shape as the directory, but here 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. 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)
Both a 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.
This endpoint measures exposure, not a verdict on the guest. A show’s brand-safety tier reflects the show’s overall content profile — appearing on a SENSITIVE- or UNSAFE-tier show does not imply the guest is unsuitable. The notes field restates this in every response.
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. 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.
  • 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_id recall by speaker.
  • Knowledge graph entities — the optional knowledge_graph_entity cross-reference attached to some guests.