benecaster_subscription_activated
Fires when a subscriber becomes active on any bridge, regardless of which membership plugin triggered the activation. This includes new sign-ups, resubscribes after a previous cancellation, subscribers imported via the Migration Wizard, and subscribers added via the Bulk Enrollment screen. The subscriber’s feed token is already in place at the point this hook fires — freshly minted for a first-time subscriber, reactivated in place for a returning one.
The $source parameter distinguishes the origin of the activation: 'new' for a first-time subscription, 'resubscribe' for a returning subscriber, 'migration' for an imported subscriber via the Migration Wizard, 'admin_enrolled' for subscribers added via Bulk Enrollment, and 'resumed' for a subscriber who undid a scheduled cancellation before it took effect — fired from three places: MemberPress, on their own mepr-event-subscription-resumed (a voluntary pause/resume feature, never an automatic payment-failure recovery); WooCommerce Subscriptions, on the woocommerce_subscription_status_pending-cancel_to_active transition; and the built-in (native) bridge, when a subscriber undoes a cancel_at_period_end from Account → Billing → Resume (which also fires the dedicated benecaster_subscription_resumed action on the same event — see that hook for when to use which).
⚠ Do not document 'resumed' as a guarantee that access was never interrupted — MemberPress is the exception. For WooCommerce and the native bridge, a 'resumed' activation is guaranteed continuous: the cancellation was undone before it took effect. For MemberPress, whether access stayed continuous depends on timing — continuous if the subscription was resumed before the paused period’s own expiry, a real gap if resumed after it. $source alone does not tell you which case you’re in.
$source is informational only — it does not change what happens to the token. Every activation, whatever its source, routes through TokenManager::generate_or_reactivate(), which never changes the token_hash on an existing row. A returning subscriber keeps the feed URL they already had, so code that caches a feed URL or token prefix should not treat a resubscribe as a new-token event. Use $source to vary messaging and analytics — welcome copy, CRM tags, win-back attribution — not to invalidate anything.
To react to the token itself, listen to the token hooks rather than branching on $source. benecaster_token_reactivated fires when a revoked row is restored in place; benecaster_token_generated fires only when there was no prior row at all. The one thing that does rotate a subscriber’s hash is a deliberate Reset Token, which does not flow through this hook.
Parameters
| Name | Type | Default | Description |
|---|---|---|---|
$user_id |
int |
— | WordPress user ID |
$show_id |
int |
— | ID of the show |
$tier_slug |
string |
— | Tier slug |
$source |
string |
— | One of 'new', 'resubscribe', 'migration', or 'admin_enrolled' |
Examples
Tag subscriber in email platform by source
add_action( 'benecaster_subscription_activated', function (
int $user_id,
int $show_id,
string $tier_slug,
string $source
) {
$email = get_userdata( $user_id )->user_email;
if ( $source === 'new' ) {
my_email_platform_subscribe( $email, [
'tier' => $tier_slug,
'show_id' => $show_id,
'list_tag' => 'new-subscriber',
] );
} elseif ( $source === 'resubscribe' ) {
my_email_platform_reactivate( $email, [
'tier' => $tier_slug,
'show_id' => $show_id,
] );
}
}, 10, 4 );Notes
It fires from the subscription listener wired to all active bridges at init priority 20, so it fires regardless of which membership plugin is active on the site.
Need this built rather than just documented? See our services →