Skip to main content

benecaster_token_reactivated

Action Premium

Fires when a previously revoked token is restored to active status — for example, when a cancelled subscriber resubscribes to the same show. The existing token row is updated in place, so the subscriber’s feed URL is unchanged and their podcast app resumes receiving private content on its next poll without any manual intervention.

This hook and benecaster_token_generated are mutually exclusive per activation event — benecaster_token_generated fires on a fresh token insert; benecaster_token_reactivated fires on the revived-row path. Use this hook when you need to react specifically to a returning subscriber rather than a brand-new one.

Parameters

Name Type Default Description
$token_id int — ID of the reactivated token record
$user_id int — WordPress user ID
$show_id int — ID of the show
$tier_slug string — Tier slug for the reactivated subscription
$via string — How it came back. `activation` (`TokenManager::REACTIVATED_BY_ACTIVATION`): a membership became active again, on the same URL, including during **Sync existing members**. `reset` (`TokenManager::REACTIVATED_BY_RESET`): a podcaster's **Reset Token** reinstated them, whatever the revocation reason, on a new URL. Declare `10, 5` to receive it; a callback registered for four arguments keeps working without it.

Example

add_action( 'benecaster_token_reactivated', function( int $token_id, int $user_id, int $show_id, string $tier_slug ) {
    // Log the returning subscriber for win-back attribution.
    my_analytics()->track( 'subscriber_returned', [
        'user_id' => $user_id,
        'show_id' => $show_id,
        'tier'    => $tier_slug,
    ] );
}, 10, 4 );

Notes

The $token_id is the same ID as the original token — the row is updated in place, not replaced. On activation no new plaintext token is minted and the subscriber's feed URL does not change. On reset the URL is new, reported by benecaster_token_reset, which fires straight after, and $tier_slug is the tier the token held when it was revoked.

Benecaster's own listeners write subscriber history (one return, admin on a reset), re-check badges and send the token.reactivated webhook. None sends email.

Not every reactivation attempt reaches this hook. When the revoked row was revoked by an admin action, reactivation is refused and benecaster_token_reactivation_blocked fires instead. The two are mutually exclusive per activation dispatch.

Need this built rather than just documented? See our services →