Particle Pro
activePodcast API for transcripts, mentions and sponsorship data. 140,000+ podcasts transcribed, diarized and speaker-identified within minutes of airing, about 28,000 episodes a day. Search transcripts by keyword or meaning, track brand and company mentions with alerts, pull sponsor and ad-read data and rankings. REST API plus an MCP server for AI agents. Also company, people and topic intelligence.
Settled via Coinbase.
- Transactions · 30d
- 570
- Volume · 30d
- $7.91
- Unique buyers · 30d
- 15
- Uptime · 30d
- 92.4%
- Latency p50
- 78ms
- Reported calls · 30d
- 505
Endpoints (216 live)
GET/v1/podcasts/lookup— Look up podcasts by external platform identifier. Resolves one or more external platform identifiers (Apple Podcasts collection IDs, Spotify show IDs, YouTube channel IDs, …) — or RSS feed URLs via platform=rss — to Particle podcasts. (0.01 USDC on Base)GET/v1/podcasts/guests/:id/appearances— List appearances for a podcast guest. Returns the chronological list of episodes a guest has appeared on, most recent first. (0.03 USDC on Base)GET/v1/entities/types— List entity types. Returns the entity categories supported as values for the type query parameter on /v1/entities and the entity_type query parameter on /v1/podcasts/episodes/search. (0.01 USDC on Base)GET/v1/companies— List companies. Returns a paginated list of companies. (0.01 USDC on Base)GET/v1/podcasts— List and search podcasts. Returns a paginated list of podcasts, with filters for topic, language, suitability tier, popularity, and format. (0.01 USDC on Base)GET/v1/podcasts/:id/episodes— List episodes for a podcast. Returns a paginated list of episodes for a specific podcast, identified by slug (e.g., 'all-in') or ID. (0.03 USDC on Base)GET/v1/entities— List entities. List knowledge graph entities (people, organizations, places) across all podcast content. (0.01 USDC on Base)GET/v1/podcasts/guests— List podcast guests. Returns a paginated directory of Persons who have appeared on at least one podcast episode in a non-host listing role. (0.03 USDC on Base)GET/v1/podcasts/episodes— List episodes. Returns a paginated list of podcast episodes across all podcasts. (0.01 USDC on Base)GET/v1/podcasts/:id/related— List related podcasts. Returns the shows most related to a podcast, best first, each with a calibrated score, a coarse band (strong, moderate, weak) to branch on, and — with include=basis — the signals behind the pairing: content similarity (0.03 USDC on Base)GET/v1/podcasts/episodes/search— Search podcast episode content. To find podcasts (shows) by name or topic, use /v1/podcasts/search?q=…. (0.03 USDC on Base)GET/v1/topics— List topics. Returns the hierarchical topic taxonomy. (0.01 USDC on Base)GET/v1/podcasts/search— Search podcasts. Searches the podcast catalog by show name — the canonical podcast search. (0.01 USDC on Base)GET/v1/entities/search— Search entities. Find a person, company, or knowledge graph entity by free-text query — a name, partial name, nickname, stock ticker, @handle, or website domain. (0.01 USDC on Base)GET/v1/podcasts/rankings/categories— List ranking categories. Returns every category currently represented in the rankings dataset, optionally restricted to a single source. (0.01 USDC on Base)GET/v1/podcasts/rankings/sources— List ranking sources. Returns each (source, chart_type) pair available on this API together with row counts and freshness for the live snapshot. (0.01 USDC on Base)GET/v1/podcasts/advertising/leaderboard/preview— Get advertising leaderboard preview. Returns the top 10 advertising sponsors of the trailing 7 days ranked by the chosen metric, each with its rank movement versus the equivalent 7-day window ending 30 days ago. (0.01 USDC on Base)GET/v1/podcasts/rankings/countries— List ranking countries. Returns every country currently represented in the rankings dataset, optionally restricted to a single source. (0.01 USDC on Base)GET/v1/podcasts/segments/1/transcript— Get segment transcript. Returns the diarized transcript for a specific segment. (0.03 USDC on Base)GET/v1/podcasts/1/external-links— List a podcast's third-party platform presences. Returns every third-party platform on which the podcast has a known presence — podcast directories (Apple Podcasts, Spotify, Castbox, …), social profiles (X, Instagram, TikTok, …), video (0.04 USDC on Base)
+196 more endpoints.
MCP tools (28)
particle-pro https://api.particle.pro/mcp
particle_alert_create— Create an alert that watches a single entity and sets up recurring email delivery to external recipients whenever it is mentioned on a podcast episode (kind=ENTITY_MENTION) or appears as a speaker (kind=PODCAST_SPEAKER). Pass the entity slug from a resolve tool — resolve a name with particle_entity_resolve, then create the alert with the slug it returns. An alert watches exactly one entity; to cover several entities, call this tool once per entity. An active alert emails future matches to its configured recipients at the selected delivery cadence until paused or deleted. Only recipients verified for your organization receive alert emails; pending recipients may be saved but stay silent until verified. When a name has no entity slug, or its entity has no podcast coverage (a startup known by a brand that differs from its legal name, a product, a drug, a code word), create a kind=KEYWORD_MENTION alert with `keyword` instead of `entities`. It fires whenever the phrase is spoken — the matparticle_alert_delete— Delete an alert. This is a soft delete: the alert stops producing matches and disappears from particle_alert_list, but its past matches and deliveries are retained for audit. To pause an alert instead of removing it, use particle_alert_update with is_active=false.particle_alert_get— Fetch a single alert's full configuration — title, kind, cadence, watched entities (with names), notification emails, and any active filters (languages, relevance, source_popularity, speaker_roles). The `filters` section is omitted when the alert carries none. By default the response is just the configuration; request include=['matches'] to embed the most recent matches it has caught and include=['deliveries'] for the email audit log. For the full, paginated match history with transcript excerpts, use particle_alert_list_matches.particle_alert_list— List the alerts in your project, newest first. Each entry carries the alert `id` — feed it into particle_alert_get for full configuration, particle_alert_list_matches for what it has caught, or particle_alert_update / particle_alert_delete to manage it.particle_alert_list_matches— List the matches an alert has caught, newest first — the payoff of an alert. Each match names the watched entity and the podcast episode it was detected on (with episode and podcast slugs that feed particle_podcast_get_episode and particle_podcast_resolve). Use view=detailed to include the transcript excerpts around each mention, and after/before to scope to a date range. Backfilled matches (from the past-week sweep at creation) are flagged and never triggered an email.particle_alert_preview— Preview how often an alert would fire BEFORE creating it. Sweeps the past N days (default 7, max 30) for the given entity (or keyword, for kind=KEYWORD_MENTION) and returns the total match count, a per-day breakdown, and a small sample of the most recent matches with episode context. Use this to size an alert (REALTIME vs DAILY vs WEEKLY cadence) or to confirm the entity slug watches the right thing, then call particle_alert_create with the same entity slug (for KEYWORD_MENTION, the same keyword instead). Pass the same `filters` you plan to save so the estimate matches what the alert would surface — the languages and speaker_roles axes narrow the sweep; relevance and source_popularity are read-time projections that don't, so the count is an upper bound when relevance=RELEVANT. Starts a background sweep and caches its progress and results; it does not create an alert or send notifications.particle_alert_update— Update an existing alert. Only the fields you pass change; the entities and notifications lists, when provided, replace the whole set (pass a single entity slug from the resolve tools, same as particle_alert_create — an alert watches exactly one entity). A KEYWORD_MENTION alert takes a new `keyword` instead of `entities`. Use is_active to pause or resume an alert without deleting it. An alert's kind is fixed at creation — to change it, create a new alert. Notification changes affect future recurring email delivery to external recipients; resuming an alert restarts delivery to its configured destinations. Alert emails follow delivery_cadence until paused or deleted. Only recipients verified for your organization receive alert emails; pending recipients may be saved but stay silent until verified. The optional `filters` object replaces the alert's filter set wholesale — omit to leave the existing filters unchanged, send {} to clear all filters. Same four axes as particle_alert_create.fparticle_call— Dispatch any public Particle tool by name. Compatibility fallback for harnesses that block calling tools that weren't advertised on tools/list — every public Particle tool is executable by name, so prefer calling discovered tools directly when your harness allows it. Identical metering and plan gating apply either way. Use particle_catalog to discover tool names and input schemas.particle_catalog— Browse the full Particle tool catalog. Your tools/list shows only the default categories, but EVERY public Particle tool is callable by name regardless of what was advertised — call this tool to discover the rest. Without arguments: the categorical menu (every category with tool names, one-line summaries, and an `↳` line listing each tool's expand options). With `category`: the full input schema for each of that category's tools, ready to call. Two conventions the one-line summaries don't convey, so read tools through this lens: - Tools are lean by default and EXPAND. Most return a minimal payload and opt into richer sections via an `include` array (e.g. a company's people, products, and competitors; a person's roles and podcast appearances) or change behavior via a `mode`/`format` switch. The `↳` line names these — a tool does far more than its summary alone implies. - Responses are a graph; slugs are edges. A slug a tool returns (person, company, podcast, episode, publisher, guest)particle_company_get— Return a bundled profile for one company: identifiers (slug, ticker, domain, CIK, QID, linked entity), name, and description. Request optional sections via `include`: 'people' for current leadership and notable people (person slugs feed `particle_person_get`), 'products' for the three-level product hierarchy, 'competitors' for the competitor list, 'external_links' for the company's LinkedIn, social profiles, domain, Wikidata QID, SEC CIK and tickers. The default response is lean — include only what you need. For sponsor/advertising analytics on this company, use `particle_company_get_podcast_ad_presence` instead.particle_company_resolve— Resolve a company by free-text name, ticker, SEC CIK, Wikidata QID, or domain. Returns candidates with the agent-facing identifier (`slug`, falling back to `domain` or `id`) you should pass to `particle_company_get`, `particle_company_get_podcast_ad_presence`, `particle_podcast_find_mentions` (as `company_slug`), or `particle_podcast_list_episodes`. At least one identifier is required. Multiple are ANDed together — useful for disambiguating (e.g. ticker plus a name hint). For people or other knowledge-graph entities (not companies) use `particle_entity_resolve` instead.particle_entity_get— One knowledge-graph entity's profile: name, kind, description, and Wikipedia link. Use it to confirm what a slug from `particle_entity_resolve` actually refers to — especially for the long tail that isn't a person or company (places, organizations, events, products, concepts). When the entity is a linked person or company the response carries the person_slug / company_slug — prefer `particle_person_get` / `particle_company_get` for those, which return the full profiles. Entity slugs feed `particle_podcast_find_mentions`, `particle_podcast_get_episode_timeseries`, and the alert tools.particle_entity_resolve— Resolve any named thing — person, company, place, or other entity — by free-text name in one union search. Each candidate carries a `type` and the canonical `slug` for that type: - `person`: the canonical person slug. Feed it into `particle_person_get`, every `person_slug` parameter (`particle_podcast_find_mentions`, `particle_podcast_search_transcripts`, `particle_podcast_list_episodes`), or `particle_podcast_get_guest`'s `guest_slug`. - `company`: the canonical company slug. Feed it into `particle_company_get` and every `company_slug` parameter. - `place`/`other`: a bare entity slug. Feed it into the `entity_slug` parameter on `particle_podcast_find_mentions`, `particle_podcast_search_transcripts`, and `particle_podcast_list_episodes` to filter by that entity. Use this first whenever you only have a name and don't know what kind of thing it names. If you already know it's a person, `particle_person_resolve` ranks people only; for companies with a known ticker, domain, CIK, orparticle_person_get— Return a person's profile: name, current role, and bio, keyed by the canonical person slug from `particle_person_resolve`. Request optional sections via `include`: 'external_links' for LinkedIn/Wikipedia/social profiles, 'podcast_appearances' for their most recent podcast appearances (episode and podcast slugs included for follow-up calls), 'companies' for the full role history. The default response is lean. For podcast-guest analytics (appearance stats, suitability exposure, co-appearance graph) use `particle_podcast_get_guest` with the same slug.particle_person_resolve— Resolve a person by free-text name. Returns ranked candidates with the canonical person `slug` — the stable handle accepted by `particle_person_get`, by every `person_slug` parameter (`particle_podcast_find_mentions`, `particle_podcast_search_transcripts`, `particle_podcast_list_episodes`), and by `particle_podcast_get_guest`'s `guest_slug`. For bulk resolution, pass a comma-separated `query` — each name resolves independently in one call. For organizations, places, or mixed/unknown entity kinds use `particle_entity_resolve`; for companies with a known ticker or domain use `particle_company_resolve`.particle_podcast_find_mentions— Find dialogue lines where a specific person or company is named in podcast transcripts. ## Three response modes **`format="summary"` (default, wide scan).** Returns up to `limit` episodes (reverse-chronological), each with metadata + the first 10 mention-only lines (just the lines naming the entity, no surrounding dialogue). Use this to see *what's been said across episodes* and decide which episodes are worth reading in full. Paginate older episodes with `cursor`. **`format="detail"` (narrow drill-in).** Requires `episode_slug`. Returns the full mention windows with `context_lines` of surrounding dialogue around each mention. Pass one slug for a single episode, or up to 10 comma-separated slugs (e.g. `episode_slug="all-in-200,all-in-201,all-in-202"`) to multi-get several episodes in one call. `limit`/`cursor` don't apply. **`format="compact"` (screening).** The same episodes as summary, each with its mention count, the strings it was mentioned as, and the segments carrying the menparticle_podcast_get_episode— Return a bundled overview of one podcast episode: title, podcast, speakers (with entity slugs), top mentioned entities, and segment/clip counts. By default the response is lean — counts plus the top mentioned entities. Request optional sections via `include`: 'segments' for the structural outline with timestamps, 'entities' for the complete entity list, 'clips' for engagement-ranked highlight clips, 'topics' for topic classifications with slugs, or 'transcript' for the dialogue transcript (narrow it by speaker or time range via `transcript_speaker` / `transcript_start` / `transcript_end` — full transcripts are large). For "every line about X in this episode" use `particle_podcast_find_mentions` with `episode_slug` instead — that returns the dialogue around each mention with `is_mention` flags. For the ad reads inside the episode use `particle_podcast_get_episode_ads` (premium).particle_podcast_get_episode_timeseries— Time-bucketed episode counts — the purpose-built answer to "how often is X discussed over time". Counts episodes matching the same filters as `particle_podcast_list_episodes` (person, company, entity, podcast, keyword, language, duration, transcript availability) per day, week, or month, plus range totals. `keyword_search` additionally counts matching transcript segments per bucket (exact counts); `semantic_search` does the same by meaning, with the same similarity threshold as `particle_podcast_search_transcripts` (lower bounds for pathologically broad queries), and requires `published_after`. The two cannot be combined. Use this for appearance, publication, or topic trend lines instead of paging `particle_podcast_list_episodes`, `particle_podcast_find_mentions`, or `particle_podcast_search_transcripts` once per period. Buckets are UTC-aligned, zero-filled, and Monday-aligned for weeks; ranges are capped at 1000 buckets. At least one of podcast_slug, person_slug, company_slug, entityparticle_podcast_get_guest— A guest's podcast-appearance profile: lifetime stats (appearances, distinct podcasts, first/last appearance) plus their most frequent podcasts. Guests are people — the same slug works with `particle_person_get` for the biographical profile. Request optional sections via `include`: 'appearances' for the most recent episode appearances (episode and podcast slugs included for follow-up calls), 'podcasts' for the per-podcast rollup, 'suitability' for brand-suitability exposure across the podcasts they appear on, 'recommended_podcasts' for the five shows they could plausibly appear on next — shows related to the ones they have guested on, minus those, with the venues behind each pick (the pitch list; branch on each row's band). Returns not_found for people who exist but have never appeared on a podcast — use `particle_person_get` for those.particle_podcast_get_rankings— Podcast chart rankings from Apple Podcasts and Spotify, in four modes: - `chart` (default): the current chart for a source/country/category slot, or — with `podcast_slug` — every chart slot that podcast currently holds. - `movers`: the biggest rank changes over `window_days` (risers, fallers, debuts, exits). - `history`: past snapshots for a chart slot, or — with `podcast_slug` — one podcast's chart history over time. - `slots`: the valid slot values — every source, country, and category_slug with live chart data — so filter values are discovered, not guessed. `source` narrows the country/category listings; other filters are ignored. Each row carries the matched `podcast_slug` when the chart entry is in the catalog — feed it into `particle_podcast_resolve` or any podcast tool. For a single podcast's at-a-glance chart presence, `particle_podcast_resolve` with `include: ["rankings"]` is one call instead of two.particle_podcast_list_clips— Browse AI-extracted highlight clips across the catalog, ranked by engagement potential — the shareable moments. Filter by podcast, episode, clip type (FUNNY, CONTROVERSIAL, INSIGHTFUL, ...), minimum engagement score, or speaker — `speaker` takes a person slug and returns only clips of that person talking ('an insightful Sam Altman clip'). Pass `clip_id` for one clip's full detail (description, social-hook intro, speaker, audio URL), plus `include: ["transcript"]` for its dialogue. For text-based clip discovery — finding clips about a topic or entity — use `particle_podcast_search_transcripts` instead: matching clips arrive inline on each search result. Episode slugs on every row feed `particle_podcast_get_episode`.particle_podcast_list_episodes— List episodes across the catalog with rich filters: by podcast, person, company, language, date range, duration, or transcript availability. By default it lists the episodes we have ingested. Pass `transcript_status` with `podcast_slug` to reach the show's back catalogue — older episodes discovered in its feed but not transcribed, marked requestable. Their transcript, segments, speakers and entities do not exist until one is requested. Use this for episode-level discovery when you only need metadata (title, duration, speakers, counts). For dialogue around a person in any episode, use `particle_podcast_find_mentions`. For ranked retrieval by topic, use `particle_podcast_search_transcripts`.particle_podcast_list_guests— Browse podcast guests across the catalog, in two opinionated modes: - `directory` (default): the guest directory ranked by lifetime appearances (guests with 2+ appearances). - `trends`: who's making the rounds right now — guests with appearances on 2+ distinct podcasts in the last 30 days, which surfaces cross-show press tours rather than show regulars. The press-tour shape is enforced: every in-window appearance must be on a different podcast, each needs 5+ minutes of identified speaking time, mononymous catch-all people are excluded, and the in-window rate must be a 2x spike over the guest's lifetime baseline. `podcast_slug` switches the directory to one show's roster: every guest who has appeared on that podcast, ranked by appearances on the show (one-off guests included). `topic_slug` narrows either corpus mode to guests appearing on episodes about that topic. Guest slugs ARE person slugs — feed them into `particle_podcast_get_guest` for the appearance profile or `particle_perparticle_podcast_list_related— List the shows most related to a podcast, best first — "shows like this show". Each result carries the related show's slug, a calibrated score in (0,1], and a coarse band (strong: same beat and audience; moderate: overlapping subject or audience; weak: a loose connection) to branch on. Add `include: ["basis"]` to see WHY each pair is related: content similarity of recent episodes, shared topics, shared guests (named), same publisher, shared sponsors — use it to explain a recommendation or to keep only pairs related for the reason you care about (shared guests for booking, content for media planning). Related sets are precomputed per show from its transcripts, topic profile, guest roster, network and advertisers, restricted to the show's language. Only shows above a relatedness floor are listed, machine-generated and farmed feeds are never listed, and a publisher's duplicate feeds of one show appear once. An empty FIRST page is not an error: its `coverage` says whether the set is not cparticle_podcast_list_related_episodes— Episodes from OTHER shows that cover the same story or subject as a given episode, best first — a live nearest-neighbour search over episode content, reranked on shared salient entities, shared topics and a shared news story. Each row carries a calibrated score and a band (strong / moderate / weak) to branch on; pass `include: ["basis"]` to see the signals behind every match. Each show contributes at most two episodes, the same content republished on another feed is collapsed to one row, and feeds the screens flag as machine-made or syndication spam are excluded. Use it when you already have an episode and want its coverage elsewhere ('who else covered this?'). Add `published_within_days` (7–30) to keep to the same news cycle; `same_podcast: true` admits the show's own episodes, which are otherwise excluded. Do NOT use it to find dialogue about a topic — that is `particle_podcast_search_transcripts` — nor to find every line naming an entity, which is `particle_podcast_find_mentions`.particle_podcast_resolve— Find a podcast by free-text title, exact slug, iTunes ID, or RSS feed URL. Returns slug, title, episode count, bias, and the top recurring speakers (with entity slugs). Use the slug as the agent-facing handle to feed into other podcast tools (`particle_podcast_find_mentions`, `particle_podcast_list_episodes`, `particle_podcast_get_sponsors`). Free-text matching is forgiving — typos, missing or extra words, and pasted episode titles all work. Results are ordered best-match-first; text matches carry a `match_quality` field, and an empty list means the catalog has no plausible candidate. With all identifiers omitted, returns the most recently updated podcasts — useful for browsing the catalog when you don't have a name in mind. Narrow free-text browsing with `topic_slug` (topic concentration, descendants included), `suitability_tier`, or `min_popularity` (global popularity percentile over charting podcasts). Optional hydrations attach extra data to each result in the same call: - `inparticle_podcast_search_transcripts— Search the podcast catalog by what is said in episodes — by meaning (`semantic_search`), by exact phrase (`keyword_search`), or both at once (hybrid ranking). This is THE way to retrieve relevant dialogue, segments, and clips: each result is one segment of one episode with bounded transcript windows pinpointing the highest-relevance lines, plus any highlight clips that overlap the segment inline on the match. Segments partition an episode's transcript — where start_line and end_line are present, every spoken line belongs to exactly one segment and one segment's end_line + 1 is the next one's start_line. They are contiguous in transcript lines, not in wall-clock seconds: the seconds between one segment's end_seconds and the next's start_seconds contain no transcribed speech. These matches do not carry the line ranges themselves — fetch them with `particle_podcast_get_episode` and `include: ["segments"]`, where their absence marks an episode segmented by an earlier version, a small sharparticle_topic_browse— Navigate the topic taxonomy. Without `parent_slug`, returns the top-level roots (Politics, Business, Technology, etc.). With `parent_slug` set, returns the direct children of that topic. Topic slugs use a `parent/child` convention (e.g. `politics/elections`) and let agents browse the hierarchy to find well-named categories.
First seen · last seen · last active