Skip to main content
Particle API extracts every sponsor read from every transcribed episode, attributes them to a company in the knowledge graph, and aggregates the result. You get sponsor-side analytics — who advertises where, how often, with what read style — without scraping audio yourself.
Available to MCP agents in the opt-in podcast_advertising category as particle_company_get_podcast_ad_presence, particle_podcast_get_sponsors, and particle_podcast_get_sponsor_leaderboard.

​
Per-company advertising

The fastest way to see how a single company shows up as a sponsor:
Response (truncated)
read_type_breakdown distinguishes host-reads from pre-recorded spots. placement_type distinguishes PRE_ROLL / MID_ROLL / POST_ROLL. recent_ads includes per-product attribution where the read called out a specific product line, plus segment timing within the episode — see Per-episode ads below for details. To see which podcast publishers a company advertises across — and how much of each publisher’s catalog it covers — use the sponsor→publishers flip and pass the company’s slug or domain as the {id} path parameter. When the value resolves to a company (not a specific sponsor), the response aggregates every ad with sponsor_company_id = <company> across all the company’s deduped sponsors. Pass a specific sponsor ID to scope to that single alias instead.

​
Per-podcast advertising summary

Same idea, inverted — for a single podcast, who’s sponsoring it?
Response (truncated)
A useful proxy for category fit — crypto-native sponsors dominate All-In, for example.

​
Per-episode ads

When you already have an episode in hand — for example, drilling in after list-episodes or after a transcript-based search — fetch the individual ad reads detected in that episode:
Response (truncated)
company resolves the sponsor read to a knowledge-graph company so you can join against company endpoints. Network promos (cross-promotion of other shows in the same network) are filtered out. For rolled-up views across episodes, see Per-podcast advertising summary and the Sponsor leaderboard below. Each ad carries the segment timing — start_seconds, end_seconds, duration_seconds — measured against the episode timeline. That’s enough to align ads with the transcript, measure read length, or join with the raw audio offset for downstream analysis. The most-active sponsors across the catalog:
Response (truncated)
Filter by metric (ad_count, podcast_reach, or episode_reach) to change the ranking dimension; by since / until to scope to a time window; by company_id to constrain results to one sponsor’s brand family; or by publisher_id (slug or ID) to restrict the leaderboard to ads on one publisher’s catalog — useful for asking “who are the top sponsors within iHeartPodcasts.” Which sponsors run alongside each other on the same episodes — a useful signal for media-buying overlap, attribution analysis, or competitive positioning:
Response (truncated)
Resolve a sponsor by domain, slug, or canonical ID, then list the podcasts they sponsor:
List the individual ad segments attributed to a sponsor — newest episodes first — optionally scoped to a single podcast. Results agree with the ad_count values from the sponsor podcasts endpoint, so a podcast reporting 30 ads yields exactly 30 segments here. Network promos are excluded.
Each row is a standard segment with read_type, timecodes, audio_url, and the parent episode. Use since/until to window by episode publication date.

​
Publisher-level rollups

To roll up ads across every podcast a publisher owns — total ads, network buyers, top sponsors with podcast coverage — see Publisher advertising. That page covers the publisher profile, the publisher sponsors list (the bundle-buy signal), the sponsor→publishers flip, and the cross-publisher leaderboard.