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 four places: Restrict Content Pro, when a Cancelled membership is set back to Active before its expiration date (cancelled → active); 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).

On MemberPress it fires when MemberPress records the payment, not when the checkout form is submitted: on a one-off membership’s completed transaction or a subscription’s first completed payment, or, for a free trial, when the trial starts. A checkout that never paid fires nothing, and a MemberPress renewal does not fire this hook. The same moment applies to benecaster_token_generated and benecaster_token_reactivated on a MemberPress show.

A plan change in a membership plugin also arrives here. MemberPress, Paid Memberships Pro, Restrict Content Pro and WooCommerce Subscriptions report a subscriber’s new plan as an activation while their token is still active. Benecaster moves the token to the new tier and fires benecaster_subscription_tier_moved — never benecaster_subscription_tier_changed — so listen there for tier moves. On Paid Memberships Pro, a move between two levels mapped on the same show is such a plan change: it arrives with $source 'resubscribe', with no benecaster_subscription_cancelled before it and no token revoked or reactivated. A move to another show’s level, or to an unmapped level, still ends the old show’s access at once.

A built-in-membership member on the show’s free plan who takes out a paid plan arrives here too, with $source 'resubscribe': their free membership is replaced by the paid one and their token is kept. benecaster_subscription_tier_changed does not fire for that upgrade, so a listener that provisions paid perks only on that hook needs this one as well.

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.