Skip to main content
Particle transcribes the podcast catalog end to end and keeps it current. This page gives the scope in numbers, how quickly a new episode becomes searchable, what each analysis layer covers, and the calls that show what is available for the shows you care about.

​
The catalog in numbers

The catalog grows every day, so its numbers live in the API rather than on this page. GET /v1/podcasts/stats needs no API key, is cached for a minute, and returns the podcast total and the episodes added in the last day and week:
What the catalog contains, and where each count comes from:

​
How fresh

Feeds are polled on a schedule derived from each show’s release cadence and popularity: popular and frequent shows at least every 30 minutes, tightening to every few minutes around an expected release, and every show at least every two days. Once an episode is discovered it moves through four milestones that the feed and the stream expose: Transcription and enrichment take minutes to hours after discovery. GET /v1/podcasts/episodes/feed (every plan) and GET /v1/podcasts/episodes/stream (Enterprise) deliver episodes as they cross the milestone you choose, in ingestion order, with a cursor you can resume from.

​
What every episode carries

​
What every show carries

​
Check coverage before you build

  • A show. GET /v1/podcasts/search?q= resolves a name, and the record carries episode_count, language, popularity, and format. Holding an Apple, Spotify, or YouTube id or an RSS URL? GET /v1/podcasts/lookup resolves up to 100 per call, deterministically.
  • An episode. GET /v1/podcasts/episodes/lookup resolves Apple and YouTube ids, RSS guids (the broadest identifier, carried by about nine in ten episodes), PodcastIndex ids, and hosting-platform ids from Megaphone, Omny, Acast, and Art19. Every episode record carries has_transcript; segment_count and clip_count appear once they are non-zero, so one list call tells you what is ready and a missing count means nothing yet.
  • A person or company. GET /v1/entities/search?q= resolves the name, and every result carries mentions.podcast_episodes, the number of episodes naming it, so one call tells you whether there is dialogue to read and roughly how much. GET /v1/podcasts/mentions/timeseries shows how that volume is spread over time, and its first non-zero bucket is how far back the catalog names the subject.
  • A language. language on episode and search endpoints takes an ISO 639-1 code matched on the primary subtag, so fr covers fr-CA.
  • Charts. GET /v1/podcasts/rankings/sources, /countries, and /categories enumerate every chart tracked.
  • Entities and topics. GET /v1/entities/types and GET /v1/topics enumerate the vocabularies behind entity_type and topic_id.

​
How the data is made, and what to lean on

  • Transcripts come from speech recognition with speaker diarization; each speaker is matched to a person in the knowledge graph when the episode identifies them. A speaker with an entity is identified; a named speaker without one keeps the name used on air; a speaker the pipeline could not name carries a diarization label such as speaker_0.
  • Mentions come from entity linking over the transcript: a line is a mention when it names the entity or a known alias, and mention_variants lists the forms that matched. Mentions inside ad reads are excluded by default; pass include_ads=true to count them.
  • Search ranks segments by meaning (semantic_search), by exact tokens (keyword_search), or both, and flags the lines that drove each match. relevance_score orders results within one query; across queries, compare by rank rather than by value.
  • Clips are chosen for shareability and scored for engagement on one scale across the catalog, so min_engagement=80 means the same thing on every show.
  • Ads, bias, and suitability are classified from the transcript and refreshed as new episodes land.
  • Concepts for identifiers, pagination, and errors
  • Feed and Stream for following new episodes
  • Lookup for resolving platform ids