How Feed Tokens Work

A feed token is a long random string that acts as a subscriber’s key to their private podcast feed. It’s embedded in their feed URL and validated every time their podcast app polls for new episodes.

What a Token Is

When a subscriber signs up through your membership plugin, Benecaster generates a token — 64 random hexadecimal characters — and ties it to that subscriber’s WordPress user account and membership tier. The token is then built into a private feed URL:

https://yoursite.com/podcast-feed/?token=a1b2c3d4e5f6...

This URL is what goes into the subscriber’s podcast app. The token itself is never stored in readable form — only a secure hash is kept in the database. It’s delivered once, in the welcome email, but a subscriber isn’t stuck if they lose that email: their full feed URL is also shown on their account page ([benecaster_account]) for as long as it’s valid. Beyond that, it can’t be looked up — only reset.

What Happens on Each Feed Request

When a podcast app polls a subscriber’s feed URL, Benecaster:

1. Extracts the token from the URL
2. Hashes it and looks up the matching subscriber record
3. Checks that the subscriber’s membership is currently active
4. Determines the subscriber’s tier from the membership plugin
5. Returns the compiled feed for that tier

The entire validation happens in milliseconds. From the subscriber’s perspective, it’s just a podcast feed.

If the token is valid and the membership is active, the subscriber receives their feed.

If anything fails — invalid token, cancelled membership, revoked access — the subscriber gets your public feed instead. Their app keeps working and keeps showing episodes; they just see the public episode set rather than the private one. No error message is shown either way.

This is a per-show setting, on by default. Turn it off for a show and those requests are refused outright instead, which most podcast apps surface to the listener as a broken feed. Serving the public feed is usually the kinder default: episodes they already downloaded stay on their device regardless, so a hard failure mostly just looks like a bug.

One Token per Subscriber per Show

Each subscriber has one active token per show. If a subscriber is enrolled in your membership plugin for multiple shows, they get a separate token for each.

When a subscriber’s membership tier changes — upgrade or downgrade — their existing token remains valid. The feed content changes to reflect the new tier; the URL does not change. Subscribers don’t need to update their podcast app when their tier changes.

A Follower’s Token Becomes a Subscriber’s Token

A follower’s token and a paying subscriber’s token are otherwise the same kind of record, distinguished only by a token type. When a follower subscribes to a paid tier, their token type changes from follower to subscriber in place — same token, same feed URL. Their podcast app starts receiving the paid episodes on its next poll; no new email is sent, and there’s nothing for them to reinstall.

This only runs one direction. If that subscription is later cancelled, the token does not turn back into a follower token. It is revoked as any other subscriber’s would be, unless the listener has bought episodes outright — see A Third Type: the Purchaser below.

Token Types

Follower and subscriber are the two token types Benecaster ships with. Add-ons can register more — a type for a product a listener buys outright, for example. Only add-ons create them: there is no setting for it in your admin, and nothing for you to configure. A registered type behaves like one of the built-in types, and it counts toward your plan’s subscriber limit whenever its tier is paid, exactly as a subscriber does.

A Third Type: the Purchaser

A purchaser is a listener who bought episodes outright and has no active membership. When a subscriber with purchases cancels, their token is converted to this type rather than revoked: same token, same feed URL, still active. Their feed carries your public episodes plus what they own.

• A listener who holds nothing is revoked exactly as before. So is one whose only extra is a buy-up, which is an upgrade bought on top of a subscription and ends with it. From the outside the two look the same, which is why the difference is worth knowing.
• Re-subscribing promotes a purchaser back to subscriber in place. Their purchases stay on top.

The Token Is the Tier Record

Feed URLs can include the subscriber’s tier slug in the URL path:

https://yoursite.com/podcast-feed/your-show-slug/gold/?token=a1b2c3d4e5f6...

The tier slug in the URL is for readability only. When a podcast app polls this URL, Benecaster reads the token and looks up the subscriber’s current tier from the token record — not from the URL. The tier slug in the path is not validated against the token.

This means a subscriber who upgrades from Silver to Gold gets Gold-tier episodes immediately on their next podcast app poll, even though their URL still shows silver. Their token record is updated to Gold; the URL path simply isn’t updated. Functionally, it makes no difference.

Token Lifetime

A token is valid for as long as the subscriber’s membership is active. When a membership is cancelled or expires:

• The token is not immediately deleted — it continues to work for a short grace period depending on your membership plugin’s configuration
• Once the membership plugin reports the membership as inactive, the next request falls back to your public feed (or is refused, if you turned that setting off for the show)

Benecaster relies on your membership plugin to report membership status. If a subscriber’s membership lapses in your membership plugin but the plugin hasn’t fired the relevant event yet, Benecaster may not know immediately. Most membership plugins fire cancellation and expiry events promptly.

A Listener Who Bought Episodes Keeps Them

Every automatic ending leaves what a listener bought intact: a cancellation through your membership plugin or built-in membership, a lapsed membership, a manual grant reaching its end date, and a promotion grace period running out. In each case the token is converted to a purchaser token rather than revoked, so the feed URL keeps working and carries your public episodes plus what they bought.

The one exception is your own Remove. Removing a subscriber, or using the bulk revoke action, ends all of their access, including episodes they bought. That is deliberate, because the button exists to cut one person off. Removing a listener who paid for episodes is usually a refund conversation.

An expired licence still blocks a buyer’s feed, like any other private feed. Buying episodes is a paid feature, so it stops along with the rest when the licence ends.

Tokens Over a Plan Limit

A token can also be set aside because your account is over one of its plan limits, rather than because anything is wrong with the token itself. What happens then depends on which limit and, for one of them, on your enforcement setting.

• Over the paying subscriber limit — the newest paying subscribers past the limit receive the public feed. This happens under either enforcement setting, because an auto-upgrade takes 24 hours to mature and the account is over its limit for that day. The oldest subscribers keep private access.
• Over the total token cap — only under Cap enforcement is anyone set aside at all, and it is your free-tier listeners who lose access: their feed URL stops working and returns an error. Under Auto-upgrade, nothing happens to anyone — the plan is raised instead and every listener keeps their private feed.

Under Cap, free-tier listeners give up access first — all of them, before any paying subscriber. This is a guarantee rather than a tendency: every free-tier token is considered before a single paying subscriber is touched, and only once the free tokens are exhausted does a paying subscriber lose private access. Within each group the newest go first, so your most recent free follower is affected before a long-standing one.

A token whose tier cannot be resolved is treated as paying and sorted last, so it is never chosen while any known free token remains.

What the Listener Actually Experiences

The two limits do not produce the same outcome, and the difference is visible to the listener.

• A paying subscriber is moved to your public feed. Their app keeps working and keeps showing episodes — just the public set rather than the private one. A paying subscriber is never locked out, over cap or not.
• A free-tier listener over the token cap, under Cap enforcement, is locked out. The feed URL returns an error rather than a smaller feed, and most podcast apps report this to the listener as the feed being gone or unavailable.

The lock is deliberate. A free listener quietly moved to the public feed still shows up in the app as a working subscription, so nothing about the situation reaches anybody who can resolve it. The lock is the signal the demotion never sent.

What the locked listener should be told. Nothing is wrong with their subscription and there is nothing for them to do. Their membership, their token and their feed URL are all untouched — nothing is revoked, reset or deleted. Access returns on its own once your account is back inside its limits or your plan is raised, at the next daily validation. There is no new URL to send them and no token to reset.

The token itself is untouched in every case. When the account comes back inside its limits, or the plan is raised, private access returns at the next daily validation with no action from the subscriber and no URL to swap.

There is one exception to “the setting decides”: after 30 days in a payment-failure grace state, every active token is set aside regardless of either enforcement setting. That is a billing consequence rather than a limit consequence — see Post-Grace Behavior below, where the outcome is different again.

What a Listener Keeps When Their Feed Is Downgraded

Episodes a listener owns outright stay with them. When a listener is over the plan’s subscriber limit, or your licence is in its payment-failure grace window, they receive the public feed with what they own added on top. A listener holding something they own is also served a feed, rather than refused, when their membership ends.

Buy-ups are different. A buy-up is an upgrade bought on top of a subscription, and it drops away with that subscription. The two look alike from the outside, but only what a listener owns outright is kept.

See How Subscriber Limits Work for the limits themselves, the two settings, and which listeners count toward which limit.

Token Security

Tokens are long enough to be unguessable — 64 hex characters gives 256 bits of entropy. There is no practical way to brute-force a valid token.

However, a token embedded in a URL can be shared. If a subscriber shares their feed URL with someone who isn’t a paying member, that person gets the same feed access. Benecaster does not technically prevent this, but token reset is available if a subscriber reports their URL has been shared or compromised.

Token reset generates a new token and immediately invalidates the old one. The subscriber receives a new feed URL. See Token Reset.

Tokens and Podcast Apps

Podcast apps treat a Benecaster feed URL like any other RSS feed URL. The app stores the URL and polls it on a schedule (typically every few hours). The token in the URL is passed to Benecaster on every poll — it’s not a one-time authentication, it’s checked every time.

This means if a token is reset, the old URL stops delivering the private feed the moment the app polls again. The app does not break — the old URL falls back to your public feed, the same as any other invalid token — but the subscriber quietly stops receiving subscriber-only episodes until they swap in the new URL.

That is the main friction point of token reset, and it is worth communicating clearly before a subscriber requests one: nothing will look broken, so they have no signal that they are on the wrong URL.

Post-Grace Behavior

For the first 30 days of a payment-failed suspension, nothing changes for your subscribers — they keep receiving their full private feed. The grace window is a full-access extension, not a degraded state.

When those 30 days elapse without the billing issue being resolved, subscriber tokens are deactivated and private feeds stop working. They do not fall back to your public feed. A podcast app polling a deactivated token gets an authentication failure, not a smaller set of episodes.

From the subscriber’s perspective their feed breaks. The app reports an error or an empty feed, depending on the app. That is deliberate: someone whose paid access has ended should be told, not quietly moved onto the free tier without knowing it. Episodes they already downloaded stay on their device.

A few important details:

• The feed URL itself is not deleted or rewritten. The token is deactivated, so the same URL stops authenticating — when you recover, that original URL works again and subscribers need do nothing.
• Recovery needs nothing from your subscribers, but it is not instant. When you update billing and your license returns to valid, tokens are reactivated on the next daily license validation — so allow up to a day, and a little longer for apps to poll again. Nobody has to re-subscribe, change a URL, or re-add a feed.
• New token generation stays blocked from the moment the license enters Suspended state — new subscriber signups cannot receive a feed URL until billing is resolved.

Your subscribers are probably still being charged. Benecaster deactivating their tokens does not cancel anything. If you use an external membership plugin it keeps billing on its own schedule — it has no idea your Benecaster license lapsed. Your subscribers are now paying full price and receiving nothing.

Cancelling in Benecaster is not enough for them either — they must cancel in whatever is actually charging them, and you should tell them where that is. Chargebacks start here.

Cancelling or expiring reaches the same place

Everything above describes a payment failure running its 30 days. A cancelled licence and an expired one end private feeds the same way: token URLs return an authentication failure, they do not fall back to your public feed, and your public feed carries on untouched. Thirty consecutive days of the site being unable to reach Benecaster arrives there too, by way of the licence expiring.

One difference is worth knowing if you are looking at a token wondering why it fails. On the payment-failure path the tokens really are deactivated — you can see it. On the cancelled and expired paths nothing is done to the tokens at all; they stay exactly as valid as they were, and the request is refused before the token is ever examined. A token that looks perfectly healthy and still returns an error is not a bug and not a token problem. Check Settings → Account instead.

The practical consequence is the same in both cases: resolve the licence and the original feed URLs start working again on the next daily validation, with nothing required from your subscribers.

As of 2026-09-17, the subscriber account page and the [benecaster_feed_url] / [benecaster_qr_code] shortcodes know about this state too, and stop offering a URL, QR code, or reset button for a feed that has gone dark this way — each now reports “this feed is not currently active” instead. Before this fix, all three kept showing a working-looking URL, QR code, and a live reset button for a feed that was already returning authentication failures; resetting produced another URL that also failed, while discarding the subscriber’s existing podcast-app setup for nothing. Subscription details, tier, and join date are untouched — this only affects the URL/QR/reset surfaces. Followers are unaffected in every case above: a follower’s feed carries the public episodes and keeps working regardless of the show’s licence state, so they never see any of this.

See Payment Failure Recovery → for the full timeline and recovery steps, License status → for what each state means, and Subscriber Account Page → for what the account page shows in each of these sections.