Subscriber Can’t Access Their Feed

Work through these steps in order — most feed access problems are resolved by step 3.

1. Confirm the Feed URL Is Correct

Ask the subscriber to share exactly what URL they have in their podcast app. Common issues:

• The URL was truncated. Feed URLs are long. If the subscriber copied their URL from an email that wrapped the text across multiple lines, they may have missed part of it. The token itself is 64 characters — after ?token= in the standard form, or as the last path segment in the pretty form (/podcast/{feed-slug}/feed/{token}/, only in use if you’ve turned on Use pretty feed URLs at Settings → Permalinks) — if their token looks short, it’s been cut off.
• The URL has extra characters. Some email clients add tracking parameters or rewrite links. The URL should end with the token and nothing else.
• Something was inserted inside the token. A URL broken across lines and pasted back together, or a link mangled by a word processor, can leave stray characters in the middle of the token rather than at its ends.
• The subscriber is using a tier-slugged URL for the wrong tier. If you have multiple tiers, and their URL names one in its path (e.g. /gold/), confirm it matches their actual tier — though the tier slug is decorative and the token is what actually decides access.

On a multi-show site, the standard URL works for every show — it does not need a show slug. /podcast-feed/?token=… carries no show name and resolves from the token itself, so this is correct as-is for any show. Before a past release it only worked reliably for the first-published show, and a subscriber of any other show could receive that show’s public feed, or a 403 in strict mode. If you’re seeing that symptom, the fix is updating the plugin, not resetting the subscriber’s token — see Subscriber Seeing Public Episodes Instead of Paid Content.

Whitespace at the ends of the token is not a cause. Benecaster trims it before looking the token up — ordinary spaces, tabs and newlines always were, and non-breaking spaces, zero-width spaces and byte-order marks (the kind email clients and word processors leave behind) are trimmed too. A URL that merely picked up trailing whitespace when it was highlighted will still resolve correctly.

The Subscribers list copy control does not give you a working URL to send. Tokens are stored hashed, so no admin screen — including this one — can display or copy the subscriber’s actual working token; the copy control there copies a masked …?token=<prefix>..., which no app can use. To get them a working URL, reset their token in the subscriber panel — either Reset only or Reset and send email shows the full new URL once, right after the reset, with a Copy new feed URL button. Copy it then, or let Reset and send email deliver it for you. (A subscriber can also reset their own token from their account page.)

The correct URL format is:

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

Pretty permalinks, if the podcaster has turned on Use pretty feed URLs (Settings → Permalinks), look different from the query-string form above:

https://yoursite.com/podcast/{feed-slug}/feed/{token}/

Both forms are valid and work identically. A URL in this form whose Feed Slug has since been renamed still resolves correctly — Benecaster reads the show from the token itself, not from the slug in the path.

---

2. Check the Subscriber’s Membership Status

Go to Benecaster → Subscribers and find the subscriber. Check:

• Is their membership active? If their subscription has expired or been cancelled in your membership plugin, Benecaster revokes their token and (by default) routes their feed URL to the public feed — their podcast app keeps working but shows only public-tier content. If their feed appears empty, the show may simply have no public episodes. Resolve the membership issue in your membership plugin, then issue a new token. See Subscriber Seeing Public Episodes Instead of Paid Content if this is what you’re seeing.
• Is their tier mapped? If their membership tier isn’t mapped to a Benecaster tier, no feed is generated. Go to Benecaster → Settings → Subscription and confirm their tier is mapped.
• When did they last access the feed? The Last Accessed column shows the last time their podcast app polled the feed. If it shows a time in the past, the URL is probably working — the subscriber may just need to refresh manually in their app.

---

3. Check Whether a Token Exists

In Benecaster → Subscribers, if the subscriber doesn’t appear at all, their token was never generated. This usually means the subscription activation event wasn’t received from your membership plugin.

To fix: use the Generate Token action on the subscriber’s record to create one manually, then send them the new feed URL. Also check that your membership plugin’s Benecaster integration is properly connected — go to Benecaster → Settings → Subscription and confirm the bridge is active.

---

4. Test the Feed URL Directly

Pasting the URL into a current browser no longer shows raw XML for a working link — it shows the feed landing page instead (the show’s artwork, one-tap app buttons, a Copy field). Seeing that page means the token is valid and passed every check — it is not proof the feed itself is healthy, since the page is served before the feed is compiled and cannot show an empty feed or a compile error. To actually inspect the XML, use curl -s "<feed URL>", a feed validator, or add the URL to a podcast app.

• The landing page — the link works. If the subscriber’s app still isn’t receiving episodes, the problem is on their end (wrong URL saved in their app, app cache, etc.) or in the feed content itself — check with curl or a validator next.
• Raw XML with episode data (via curl, a validator, or an app) — the feed is working.
• Empty RSS feed (XML with no items) — the token is valid but no episodes are available to the subscriber’s tier. Check tier mapping and episode availability dates.
• A 404 error — the feed rewrite rule isn’t registered. Flush your WordPress permalinks by visiting Settings → Permalinks and clicking Save Changes.
• A blank page or server error — a PHP error is occurring. Check your WordPress debug log.
• A 410 or 403 error — the feed is deliberately refusing the request, and this one still shows in a browser exactly as before — a refusal never gets the landing page. Which one, and why, is in the table below.

Telling the refusals apart

A podcast app reports all of these the same way — the feed is gone, unavailable, or broken. They have different causes and different fixes, and only one of them resolves without anybody touching the subscription. Open the URL in a browser and read the XML comment at the top of the response; that is what distinguishes the two errors that share a visible message.

Check Benecaster → Subscribers first, though. If the listener’s row carries a red Feed locked pill, you have your answer without opening anything — that pill means this listener specifically, and it is only ever the free-tier lock in the third row below. A red pill rules out every other cause in the table.

The two “Invalid or expired feed token” rows are the same message, so the message will not tell you which one you have — the scope will. One broken subscriber is the first row. Every subscriber broken at once, while the public feed still loads fine, is the second. Check Settings → Account before working through any per-subscriber steps; if the licence is the cause, nothing you do to an individual token will help.

The per-show “serve public feed on invalid token” toggle does not apply to the second row, and neither does the token being valid. When the licence has ended, any token-bearing request is refused — a perfectly valid, unrevoked token included. On the cancelled and expired paths nothing revokes tokens at all, so a subscriber whose token checks out fine will still be refused. That is deliberate: the toggle governs subscriber-level failures, and this is a podcaster-level one.

The free-tier lock is the one that is not about this subscriber at all. Nothing is wrong with their membership, their token or their URL — they are simply the listener the cap landed on, and the cap is a combined total of paid and free listeners, so gaining a paying subscriber can lock a free one who did nothing. It reverses on its own. Do not reset their token; a new token is over the cap the same way the old one was.

The Subscribers screen used to point away from this cause. Every flagged listener was labelled “Receiving public feed”, which for a locked listener is the one thing not happening to them — a podcaster investigating a dead feed read that the feed was being served and stopped looking. It now renders two distinct pills: amber Public feed for a demoted paying subscriber, red Feed locked for this case. If you are working from an older screenshot or an older note, trust the pill on the screen.

---

5. Ask the Subscriber to Re-add the Feed

If the URL is correct and works in a browser but not in the subscriber’s podcast app:

• Ask them to remove the feed from their app and add it again with the same URL
• Some apps cache a “feed not found” state and won’t retry until the subscription is removed and re-added
• If they’re on Apple Podcasts, restarting the app after re-adding can help

---

6. Reset the Token

If the above steps don’t resolve the issue, reset the subscriber’s token. This generates a new feed URL and immediately invalidates the old one. Send the subscriber their new URL.

Important: after a token reset, the subscriber must remove their old feed URL from their podcast app and add the new one. Their episode history in the app is not affected.

See Token Reset for how to reset from the admin or how subscribers can reset themselves.