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.

​
Sponsors a podcast could pitch

GET /v1/podcasts/{id}/recommendations/sponsors flips the question for a show selling its own inventory: which advertisers buy shows like mine, but not mine yet? It takes the show’s precomputed related shows, collects the sponsors those shows run, and ranks each sponsor by how related the venues are, how much it buys there, and how recently, dropping anything already on the show’s own roster. It is a prospecting list, not a prediction: the right reading is “advertisers your peer shows carry that you do not.” The podcast detail embeds the first five with include=recommended_sponsors on GET /v1/podcasts/{id}, gated the same way as this endpoint.
Response (truncated)
A show whose related set has not been computed yet gets 200 with an empty data array. Who sponsors this show is GET /v1/podcasts/{id}/advertising; a sponsor’s full footprint is GET /v1/podcasts/advertising/sponsors/{id}/podcasts. MCP: include: ["recommended_sponsors"] on particle_podcast_resolve.

​
Shows a company could advertise on next

GET /v1/companies/{id}/podcast/recommendations is the buy side: which shows are most like the ones a company already advertises on, that it does not buy yet? It takes the shows the company’s sponsors run ads on, weights each by how much the company advertises there, follows each one’s precomputed related shows, and ranks every show the company has never bought by the compounded relatedness. In the temporal holdout it recovered the shows advertisers went on to buy at 13× the rate of category-by-popularity and 8× the rate of “most-bought shows overall”. Premium, like the rest of the company advertising surface.
Response (truncated)
A company with no podcast advertising, or whose bought shows have no computed related sets yet, gets 200 with an empty data array. Where the company advertises today is GET /v1/companies/{id}/podcast/advertising/podcasts. MCP: include: ["podcast_recommendations"] on particle_company_get.

​
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. company.slug is the knowledge-graph slug and the stable key to build links from; company.id stays domain-preferred (okx.com). 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.