Add-ons FAQ

Per-tier episode scheduling lets you set different release dates for the same episode across different subscriber tiers. Premium subscribers get it Tuesday. Your free tier gets it Friday. The public never gets it. Each rule is set per episode, with show-wide defaults so most episodes just work automatically.

Patreon’s Early Access comes closest — you can schedule an episode to automatically transition from paid to public on a set date. But that’s one transition, between two audiences. No platform lets you schedule the same episode across multiple paid tiers with a different date for each — premium gets it Tuesday, free tier gets it Friday, all automatic.

When a subscriber signs up, Benecaster generates a unique, cryptographically random URL for them:

yoursite.com/podcast-feed/?token=abc123xyz

That URL is theirs alone — and it never changes. Their podcast app polls it like any other podcast feed. In the background, every request is validated: is this token active? What tier is this subscriber on? What episodes are they entitled to today? The RSS XML returned is compiled on the fly based on those answers.

For you as the podcaster: there is one feed per subscriber, not one feed per tier. You don’t manage a “Premium feed” and a “Basic feed” as separate URLs. You don’t turn off a subscriber’s access to a feed when they downgrade — the same URL continues to work, it just returns the episodes their new tier is entitled to. There’s no churn to manage when someone moves from one paid tier to another, or from paid to free. The subscriber keeps their URL regardless of where they sit.

For your listeners: because the URL never changes, their podcast app never loses track of what they’ve already heard. Podcast apps record played status, download history, and in-progress timestamps against the feed URL. If the URL changed — as it does on platforms that issue a separate feed per tier — the app would treat it as a brand new podcast and lose that history entirely. With Benecaster, a subscriber who upgrades from free to premium sees new episodes appear in the same feed they’re already subscribed to. They don’t need to re-add anything, and they won’t be re-prompted to listen to episodes they’ve already heard.

A token is the unique identifier embedded in each subscriber’s private feed URL. Because each subscriber has a different URL, you can:

• Track exactly who is accessing their feed and when
• Revoke a specific subscriber’s access without affecting anyone else
• Reset a compromised URL for one subscriber without changing feeds for everyone
• See which subscribers haven’t polled their feed recently
• Change a subscriber’s membership tier without them doing anything in their podcatcher — their URL stays the same, their episode history stays intact, and they never have to re-subscribe

On competing platforms (including Patreon), there is no per-subscriber feed URL — tokens don’t exist, and this level of individual control isn’t possible.

Yes. Subscribers can reset their feed URL from their account dashboard on your site. This generates a new token and invalidates the old URL — useful if they believe their feed URL has been shared or compromised. Admins can also reset any subscriber’s token from the Benecaster subscriber management dashboard.

This will reset their listening history in their podcast app. Because the URL changes, the app treats the new feed as a brand new podcast — played status, downloaded episodes, and in-progress timestamps are all lost. The subscriber will need to re-add the new URL, and their app won’t remember what they’ve already heard. This is worth communicating to subscribers before they reset, so they’re not surprised when their app shows every episode as unplayed.

The core plugin includes a subscriber count stat card, a 90-day growth sparkline, and a tier breakdown panel — active count, new subscribers, and churned per tier for the last 30 days — in the admin dashboard from day one.

The Analytics Dashboard add-on adds: subscriber growth over time (by tier, with date-range controls and prior-period comparison), tier movement tracking (upgrades, downgrades), episode download counts, downloads by episode and date range, podcast app breakdown, feed engagement per tier, cohort analysis, and CSV export of any panel.

With the download proxy enabled, episode download data includes per-subscriber attribution, podcast app identification, and exact last-access timestamps — so you can see not just how many times an episode was downloaded but who downloaded it, from which app, and when. Without the proxy, feed polling data is available but per-episode download counts and app breakdowns aren’t.

Because Benecaster collects analytics data from the moment it’s installed — not from when you purchase the add-on — buying the Analytics Dashboard six months in gives you six months of charts immediately. There’s no retroactive gap.

Benchmark analytics show how your show performs relative to other Benecaster-powered podcasts. For example: “Your churn rate (3.2%) is below the platform median (5.8%)” or “Your episode reach (74%) is in the top quartile.”

This data is aggregated anonymously across all Benecaster installs. No individual subscriber data from any other show is ever visible to you — only statistical benchmarks (p25, p50, p75) drawn from the aggregate. Benchmarks are only shown when at least 10 sites contribute to a given metric, to prevent any site’s data from being reverse-engineered.

No — they measure different things, and most shows benefit from running both.

Podtrac counts downloads across your public audience. It answers the question advertisers ask: how many times was this episode downloaded? That number is IAB-certified, appears in Podtrac’s public rankings, and carries weight in a sponsor media kit.

Benecaster’s analytics answer a different question: what is your subscriber audience actually doing? Which subscribers downloaded which episodes, when, from which podcast app, and what tier they’re on. Subscriber growth, churn rate, cohort retention, tier movement — none of this is visible to Podtrac, because Podtrac has no concept of individual subscribers.

If you’re building a paid subscriber business, Benecaster gives you the data that matters for that business. Podtrac gives you the data sponsors want to see. Those are complementary, not competing.

Running both is straightforward — see Dynamic ad insertion and third-party tracking →.

When a subscriber downloads an episode, you find out. Not just that they opened their app — that they actually downloaded that episode, at that time, from that podcast app.

Without the download proxy, Benecaster can tell you when a subscriber last polled their feed. With it enabled, you get per-episode download counts broken out by subscriber and app. That’s the difference between “they subscribed” and “they listened.”

How it works: Each download request passes through your WordPress site for a fraction of a second, gets logged, then immediately redirects to the actual audio file hosted wherever you keep it. Your server never serves the audio itself — just the redirect.

What it costs you: Nothing to configure beyond enabling the toggle in Benecaster settings. The only real-world effect is more WordPress requests — every subscriber download is one more hit to your site. On a large, active show that can add up to a higher hosting bill. On a smaller show it’s negligible.

Developers can hook into the benecaster_download_redirected action to run custom logic each time a download is logged — see the hook reference for details.

Teaser gating lets you show episode content (description, show notes, maybe a transcript excerpt) to non-subscribers or lower tiers, while keeping the audio player hidden until they upgrade. It’s a “see what you’re missing” model — the subscriber can read about the episode but can’t listen without the right tier.

Player gating is the toggle that hides or shows the episode player based on the subscriber’s tier. You can also gate transcripts independently — show the transcript to premium subscribers, hide it from free-tier listeners, or the reverse.

Developers can use the benecaster_teaser_content filter to replace the built-in teaser with any custom preview — a transcript excerpt, a chapter list, a dynamic CTA — see the hook reference for details.

Yes — but language support depends on which transcription provider you choose. Benecaster works with four providers, each with different multilingual coverage:

OpenAI Whisper is the most capable choice for non-English content. It auto-detects the language from the audio itself, so a Spanish or Portuguese podcast transcribes correctly without any additional setup on your end. AssemblyAI and Deepgram have broad language coverage, but their accuracy is highest for English and a handful of major European languages — check each provider’s documentation for specifics on your language.

Benecaster currently passes audio to your chosen provider without a language hint — the provider handles detection automatically.

If your episodes switch between languages mid-episode, keep the language setting on Auto-detect. Forcing a specific language when the audio code-switches typically makes results worse — the provider will try to transcribe everything in the forced language. Of the four providers, OpenAI Whisper handles mid-episode language switching most reliably; the others tend to commit to the dominant language detected at the start.

Yes — this is called speaker diarization, and Benecaster supports it for multi-speaker shows like interviews and co-hosted podcasts. When enabled, the transcript labels each speaker throughout (“Speaker 1,” “Speaker 2,” etc.) rather than presenting a single unbroken block of text.

You enable diarization per show — it’s off by default, since solo shows don’t need it and it adds a small amount of processing time and API cost. An optional speaker count hint (set it to 2 for a standard host + guest format) keeps the labeling clean on long recordings.

Speaker support by provider:

Named speakers with Guest Manager: If you have the Guest Manager add-on installed, you can map speaker labels to real names directly in the transcript editor — “Speaker 1” becomes your name and “Speaker 2” becomes your guest’s name. Those names then appear in the displayed transcript, in SRT/VTT exports, and in the <podcast:transcript> RSS tag that Podcasting 2.0 apps display.

No. All shows use the same site-wide SMTP connection — you configure it once using a plugin like WP Mail SMTP or Fluent SMTP, and every show’s emails go through it.

Each show sends with its own From name — subscribers see the show name in their inbox, not your site name. The From address is whatever your SMTP plugin is configured to send from, which is a single site-wide setting shared across all shows.

If you need to send from a different address per show — for example, separate domains — that’s possible using the benecaster_email_from_address filter hook, but requires code and your SMTP provider configured to authorize multiple sending addresses.

SMTP setup and configuration →

Yes — Benecaster calls this feature Episode Credits. You write reusable text templates at the show level (a credits block, a sponsor note, an affiliate disclosure, a recurring call to action, whatever fits your show), then apply one to an episode with a single click. The resolved text is appended to your episode notes and appears in your podcast app’s show notes.

Credits support shortcodes. A template with [benecaster_recent_members] captures who your current subscribers are the moment you apply it — not a live-updating list, but a snapshot that stays accurate for when listeners hear the episode.

You can define as many templates as you like per show and set one as the default. The default is pre-selected in the episode editor so applying it to every episode takes one click.

No — and that’s intentional. When you apply a credit to an episode, Benecaster resolves all the shortcodes at that moment and bakes the result into the episode permanently. Editing the template afterward doesn’t touch past episodes. Only new episodes (or episodes where you click Apply again) pick up the changes.

Re-saving the episode does not re-run the stamp. The Apply button is the only trigger — a regular episode save leaves the existing credit text exactly as it is.

This matters for anything time-sensitive: a sponsor note is accurate to when the episode was created; a new-member recognition block names who had joined at that point. These shouldn’t silently update months later.

If you want to update the credit on a specific episode, open the episode editor, select the revised template, and click Apply again. Benecaster will ask you to confirm before overwriting the existing credit.

Yes. The stamped text is fully editable in the episode editor. Changing it doesn’t affect the template or any other episode — it’s just text on that episode. If you need to tweak wording, fix a typo, or add something specific to a particular episode, edit it directly.

Any shortcode you can use in episode content works in a credits template. Shortcodes are resolved at the moment you click Apply — the result is what gets saved, not the shortcode itself.

This means dynamic shortcodes like [benecaster_recent_members] capture current data at stamp time. Listeners who hear the episode six months later will see who was subscribed when the episode was created — which is usually exactly what you want for recognition copy. If you want a live-updating list, put the shortcode directly in the episode body or a template instead — either renders it dynamically on page load. See the shortcode reference for available shortcodes and their parameters.

Credits are intentionally flexible — they’re a text template applied at creation time, so the use case is anything you’d want to say consistently at the bottom of every episode, or anything where “current as of this episode” matters:

• True credits — “Hosted by… Produced by… Edited by…” — the literal credits meaning
• Sponsor copy — the advertiser’s message as it was when you published, not silently updated if the deal changes later
• New member recognition — name the subscribers who joined this week; the list stays accurate to when you published
• Recurring calls to action — “Subscribe for full access at…” applied consistently without retyping
• Show notes scaffold — a structural template that keeps the format consistent across episodes
• Affiliate disclosure — a standardized disclosure stamped on episodes that include affiliate links, applied per-episode or via a default template so you never forget it
• Legal or disclaimer text — boilerplate that needs to appear on every episode

They’re completely separate features that solve different problems.

Feed Credits (in the Guests tab of the episode editor) add structured <podcast:person> tags to your RSS feed. Podcast apps that support Podcasting 2.0 — like Pocket Casts and Podcast Addict — use these tags to display guest and host attribution. They’re data for apps, not text for listeners.

Episode Credits are free-form text — a template you write and apply to individual episodes. The text appears in your episode notes and in podcast app show notes. They’re for your listeners, not for app metadata.

Both can be used on the same episode. A guest episode might have Feed Credits listing the guest’s name and role for Podcasting 2.0 apps, and an Episode Credits block thanking the guest and including a sponsor note for listeners.

Yes. You can create as many templates as your show needs and designate one as the default. The default is pre-selected in the episode editor, so applying it requires one click. For episodes that need a different template — a guest interview template instead of the standard solo episode template, for example — just pick the right one from the dropdown before clicking Apply.

Each episode holds one credit block at a time. Applying a second template replaces the first — see Can I apply more than one credits template to the same episode? →

One episode, one credit block. Applying a second template replaces the first — you’ll be asked to confirm before it overwrites.

If you need content from two templates on one episode, the practical approach is to combine them: either create a template that covers both (a guest episode template that includes both standard credits and the sponsor note, for example), or apply one template and edit the stamped text to add whatever the other would have contributed. The stamped text is fully editable after applying — editing it doesn’t affect the template or other episodes.

Yes. Credits appear at the bottom of your episode’s show notes — in the podcast app, just like on the episode page on your site. Any app that displays show notes will show them.

What listeners see is exactly what was locked in when you clicked Apply. The credit is saved as plain text at that point, so there’s nothing to change afterward — no dynamic updates, no re-processing. What you applied is what they get.

It depends on how you’re displaying the price.

If you’re using [benecaster_tier_price] or [benecaster_pricing_table], yes — both pull the price live from your subscription bridge on each page load, so a price change in MemberPress, RCP, or whichever plugin you use is reflected on your site immediately. No page editing required.

Same for tier names: [benecaster_tier_name] always outputs the current name from your membership plugin. If you rename a tier, the shortcode picks it up automatically.

If you’ve hardcoded a price or tier name into your page content — typed directly into a block or text widget — that text stays as-is until you manually update it.

This is the reason these shortcodes exist: so a price change in your membership plugin is the only thing you ever have to do. Every page that uses the shortcode updates itself.

Dynamic ad insertion (DAI) is a way of swapping different ads into an episode’s audio depending on when and where a listener downloads it — so a listener in Chicago hears a different ad than one in Austin, and an ad campaign that ended last Tuesday is replaced automatically rather than living forever in the file.

There are two main ways this is implemented, and they work differently with Benecaster.

Redirect-prefix tracking (Podtrac, Chartable, Spotify prefix, and similar): These services wrap your audio file URL with a short redirect — your episode’s URL in the RSS feed points to their server first, which logs the download and immediately sends the listener’s app to the actual audio file. Because Benecaster uses the URL you enter in the episode’s audio field as-is, this works transparently: enter the prefix-wrapped URL, and Benecaster includes it in every private subscriber feed. Your listeners’ apps follow the redirect chain normally and the ad service sees their real location for targeting.

If you also want per-subscriber download attribution — which episode each subscriber downloaded, when, and from which podcast app — enable the download proxy in Benecaster settings. With the proxy on, your subscriber’s app hits your site first, Benecaster logs the download with full attribution, then immediately redirects to the prefix URL. Podtrac records its count from there. You end up with two complementary datasets from a single download: IAB-certified public totals for your media kit, and subscriber-level episode data for your own use.

Platform-level audio stitching (Megaphone, Acast, Omny, and similar hosting platforms): These services stitch ads directly into the audio at the moment of download, based on the listener’s location and the current ad inventory. The audio URL in your feed is their ad server’s endpoint, and that part works — your listeners’ apps hit the platform’s server and get the stitched audio. What doesn’t carry over is anything tied to the platform’s own RSS feed: per-subscriber engagement data, frequency capping, and download attribution in their reporting dashboard all depend on the platform serving the feed itself. Because Benecaster serves the private subscriber feeds instead, those platform-level analytics are unavailable. You’d be managing two separate download counts — Benecaster’s subscriber count and the platform’s audio request count — with no automatic reconciliation between them.

For most shows, Podtrac-style prefix tracking is the right tool and works without any special configuration. If you’re running a larger show with a direct ad sales relationship on Megaphone or a similar platform, reach out to support@benecaster.com before you set things up — the specifics depend on how your hosting provider handles audio delivery.

Benecaster handles paid podcast subscriptions — it doesn’t include merchandise features and doesn’t interfere with anything you set up alongside it. Selling merch on your WordPress site is entirely up to you.

WooCommerce is the natural fit. If you’re already using WooCommerce Subscriptions as your subscriber bridge, your merch store and your subscriber checkout live in the same place — one cart, one account, one checkout flow for your listeners. You add products and Benecaster keeps doing what it does.

If you’re using a different membership plugin (Restrict Content Pro, Paid Memberships Pro, etc.), a standalone WooCommerce install works just as well. It runs independently of Benecaster with no conflicts — you just manage two separate things.