benecaster_get_user_tier_for_show()
benecaster_get_user_tier_for_show( int $show_id, int $user_id = 0 ): stringReturns the active tier slug for a user’s subscription to a specific show. Reads the subscriber’s stored token record — this is the tier the token was minted for, not a live bridge query.
Not a subscription check. It reads the feed token, which an importer creates on a paid tier before anyone has paid, and which Preview as Tier overrides. To ask whether somebody holds a membership, use benecaster_user_has_active_membership().
Use this to gate content display or feature access based on the current user’s subscription tier. For live bridge-resolved tiers (used at feed delivery time), see BridgeManager::get_user_tier().
Parameters
| Name | Type | Default | Required | Description |
|---|---|---|---|---|
show_id |
int |
— | Yes | The show (post) ID. |
user_id |
int |
0 |
No | WordPress user ID. Defaults to the current user when 0 or omitted. |
Return Value
Type:
string
The active tier slug recorded on the subscriber's token, or an empty string when the user has no active token for this show.
Example
$tier = benecaster_get_user_tier_for_show( get_the_ID() );
if ( 'premium' === $tier ) {
// show premium content
}
Notes
If all you have is an email address, start somewhere else. This function takes a WordPress user ID, and source data from a membership export, a webhook payload or a CSV is usually keyed by email instead. Two email-first entry points reach the same answer:
• benecaster_get_subscriber_data() — everything about one subscriber on one show, keyed by email. Its tier key is this function's return value, so if you want the tier plus anything else, call that once rather than resolving an ID and calling this.
• benecaster_get_user_id_by_subscriber_email() — the cheap ID-only resolve, for looping over a list of addresses before calling this function per row.
Neither is a _by_email variant of this function. There is no benecaster_get_user_tier_for_show_by_email(); they are separate entry points with their own return shapes. See Subscriber Lookup for Developers for the full decision matrix.
Buy-ups are invisible here, and this is the mistake worth avoiding. The return value is the base tier slug recorded on the token — nothing else. A subscriber who has bought a buy-up still resolves to whatever tier they were already on, so gating a transcript, a downloads area or any other extra on a slug comparison lets every subscriber on that tier through and no one who paid for the buy-up in particular. Nothing errors and nothing is logged; the gate simply opens for the wrong people.
Ask the buy-up question directly with benecaster_user_has_buyup(), which is the supported way to check a grant. For an episode, use benecaster_user_can_access_episode(), which already resolves tiers and buy-ups together and is almost always the right call.
The reason for the asymmetry: a buy-up's token type is written into the episode availability table as a pseudo-tier slug, so it behaves like a tier when an episode's access is resolved. It is not part of the subscriber's tier identity anywhere else, and this function reports identity.
Need this built rather than just documented? See our services →