Skip to main content
Four calls take you from a company name to a standing watch: resolve the name to a slug, read the dialogue that names it, measure how the volume moves over time, and create an alert so new mentions come to you. Every example below was run against https://api.particle.pro.

1. Resolve the company

Search by name, ticker, domain, CIK, or Wikidata QID. The record carries every identifier, and the nested entity.slug is the handle the podcast endpoints take.
Response (truncated)
Already holding a ticker? GET /v1/companies?ticker=NVDA skips the name match. The rest of this recipe uses the slug nvidia, which every company_id parameter accepts alongside the domain and the canonical id.

2. Read every line that names it

GET /v1/podcasts/mentions returns dialogue grouped by episode, newest first, with the lines around each mention and the matched line flagged. context_lines sets how many surrounding lines you get (default 2, up to 20).
Response (truncated)
An episode’s whole mention set always arrives in one page, so mention_count and windows are complete for each episode you see. Narrow the walk with podcast_id, publisher_id, role (guest, host, and so on), language, since, and until; ad reads are excluded unless you pass include_ads=true. Page with the loop when you want everything.

3. Chart the volume over time

For “how often, and is it rising”, call the timeseries instead of paging mentions once per week. interval is day, week, or month; published_after and published_before bound the window.
Response (truncated)
Every bucket in the window comes back in one response, up to 1,000 buckets, so a daily series should cover at most about three years and anything longer should use weeks or months. The first bucket is the partial week the window opened in, so compare full weeks to each other.

4. Hand the watching to an alert

An alert watches one entity and delivers every new match by email, Slack, or a signed webhook. Create one for the company with REALTIME cadence and a webhook connection you created on Deliver alerts to a webhook:
Alerts take the company’s canonical id (3CensCwu5G2oKCFgPrNf89 from step 1). From then on each match arrives as an alert.match.created POST. Its match.windows[].lines carry the same line shape as step 2 (speaker, role, start_seconds, end_seconds, text, is_mention), so the line-level code you wrote for mentions applies; the episode block is flattened (episode.podcast_title, episode.podcast_slug, no segment per window) and each window adds a clip_url, so map that part separately. The exact payload is on Deliver alerts to a webhook. Alerts are included with the Team, Business, and Enterprise plans; preview how often one would fire before creating it with POST /v1/projects/{projectId}/alerts/preview. The full lifecycle is on Create and manage alerts.
  • Mentions for every filter on the mention endpoints
  • Companies for the identifier systems a company resolves from
  • Alerts overview for kinds, cadences, and delivery channels