Pushlane: RevenueCat Push Automation Blueprints

RevenueCat push automation should begin with subscription state, not a list of messages you want to send. A payment failed, a trial began, a purchase completed or access expired. Each state has a different job, a different tone and a different event that must stop the flow.

Pushlane receives RevenueCat webhooks server to server and bridges supported lifecycle events into its flow engine. That removes client-side purchase tracking from the critical path. It does not remove the need to choose the right trigger or to verify what the event means.

These five blueprints are ordered by operational clarity, not by a claimed universal return. Ship the flows your app can support accurately, then measure them against subscription outcomes.

The shared foundation for every blueprint

Before building a flow, connect identity and delivery.

RevenueCat's webhook includes an App User ID. Pushlane associates an APNs device with the external ID passed to identify(). Those strings need to match. The setup is described in RevenueCat App User ID and push device token matching and in the official RevenueCat customer identity documentation.

Connect Pushlane's dedicated RevenueCat webhook secret in the RevenueCat dashboard. Do not use the publishable SDK write key as a webhook credential. Then send a dashboard test event to prove authentication and a sandbox purchase to prove the real lifecycle mapping. A test webhook proves transport; it does not behave like a purchase event.

Every customer-facing flow should begin with the same guards:

• is_production is true;
• the user resolves to the expected identity;
• a supported, active iOS device is reachable;
• the relevant consent and frequency rules allow the send;
• the event properties you branch on are present in an observed payload.

RevenueCat says webhook processing must tolerate added fields and duplicate delivery. Its official webhook guide documents at-least-once delivery behavior. Pushlane deduplicates by RevenueCat event ID, while your flow should prevent two different events from starting contradictory journeys.

Blueprint 1: welcome a paid purchase

Entry: revenuecat.initial_purchase, with period_type checked so the copy matches a paid purchase rather than a trial.

Job: confirm what is now available and lead directly to the first premium value action.

initial_purchase
  -> branch: production, paid period, supported iOS device
  -> send: access confirmation plus one useful next action
  -> wait for product activation event
  -> send one setup reminder only if activation is incomplete
  -> exit on activation, refund-related state or opt-out

Copy should explain access, not congratulate the business for making a sale.

Premium is ready

Create your first weekly plan and put the new tools to work.

Use a product event such as first_premium_plan_created as the success event. An open is not activation. If a trial is represented by an initial purchase with period_type: TRIAL, route it to the separate trial flow.

For the full first-day design, map the message to the first premium value action and stop it as soon as that action is complete. A dedicated post-purchase guide follows later in this series.

Blueprint 2: help a trial reach value

Entry: the verified trial-start event available in your Pushlane catalogue.

Pushlane currently maps revenuecat.trial_started when RevenueCat sends that event. RevenueCat's current public event guide also describes trial starts as INITIAL_PURCHASE with period_type: TRIAL for common webhook flows. Treat the event you actually observe in your connected project as authoritative. Do not create a flow on a name that has never arrived.

Job: help the user experience the product and disclose the actual trial deadline without turning every onboarding message into a paywall reminder.

trial start
  -> send: one high-value action
  -> wait relative to the observed trial window
  -> exit on conversion, cancellation or expiration
  -> send: accurate deadline notice near the end

Use expiration_at_ms from the event context when available. Do not hardcode "three days left" because one product normally has that trial length. Trial duration can vary by product, store and offer.

The trial-to-paid sequence explains the complete message logic. Keep activation and purchase as separate outcomes so you can tell whether the problem is product value or price.

Blueprint 3: recover a billing issue

Entry: revenuecat.billing_issue.

Job: help a subscriber resolve a failed charge before access is lost.

RevenueCat states that BILLING_ISSUE means a charge attempt failed and does not necessarily mean the subscription expired. A grace period may retain access, a successful retry can produce RENEWAL, and an unsuccessful episode can end in EXPIRATION. See RevenueCat's event types and fields.

billing_issue
  -> send: neutral payment notice
  -> wait only within a known recovery window
  -> exit immediately on renewal
  -> transfer state on expiration
  -> optional reminder if the issue remains open

Never say "your subscription is cancelled" from this trigger. Never continue the reminder after renewal. Link to the correct store or billing management path. The detailed state machine is in recovering RevenueCat billing issues with push.

Blueprint 4: respond to cancellation before access ends

Entry: revenuecat.cancellation.

Job: acknowledge the choice and offer appropriate help during remaining access.

RevenueCat cancellation can represent auto-renew being disabled, a refund or a billing error. Pushlane does not currently project cancel_reason into flow properties. That makes cause-specific claims unsafe in a generic Pushlane flow.

Use neutral copy unless your own validated server event provides the cause:

Your plan settings changed

Review your current access and renewal details whenever you are ready.

Exit on revenuecat.uncancellation, which means a non-expired cancelled subscription was re-enabled, and on revenuecat.expiration, which moves the person into a genuinely lapsed state. Do not offer a win-back discount while the person still has the product.

The RevenueCat cancellation push guide covers these limitations and stop rules in depth.

Blueprint 5: invite an expired subscriber back

Entry: revenuecat.expiration.

Job: reconnect a former subscriber with a credible value or current offer after access ended.

expiration
  -> wait for a product-appropriate return moment
  -> branch: prior value, contact frequency, supported device
  -> send: one value-led invitation
  -> exit on renewal or initial purchase
  -> optional second send with a different reason to return

Do not assume every expiration was voluntary. Use cause-neutral language unless you have a reliable reason field in a custom event. Stop on both renewal and initial purchase because RevenueCat notes that resubscription representation can vary by platform and timing.

For copy, destination and measurement, use win-back push notifications for subscription apps.

Prevent the five flows from colliding

Five individually correct flows can still create a bad experience when they operate independently. Define a state precedence before activation.

1. Billing recovery wins while payment is unresolved and access may remain active.
2. Cancellation acknowledgment runs only when it is not a billing-error path you separately identified.
3. Expiration ends cancellation and billing messages.
4. Verified paid purchase or renewal ends every recovery and win-back sequence.
5. Product onboarding messages yield to a time-sensitive, accurate account notice.

Use exits rather than waiting for a frequency cap to hide contradictions. A cap can prevent two pushes on the same day, but it cannot make stale copy true tomorrow.

Keep a short state table next to the flow definitions:

Roll out in an order you can observe

Start with one event and one device. For each blueprint:

1. Confirm the event appears in the Pushlane catalogue from a real sandbox lifecycle.
2. Inspect the property names and values before writing a branch.
3. Run the entry through a production guard.
4. Test each stop event during every delay.
5. Verify the deep link from a terminated app.
6. Confirm a missing device or denied permission records a suppress decision.
7. Activate for a small, identifiable cohort.
8. Review state errors before reviewing performance.

The first report should answer "Did anyone receive an untrue or stale message?" Only after that gate is clean should you compare copy or timing.

Connect each flow to a business outcome

Give every automation one primary outcome:

• paid welcome: completion of the first premium value event;
• trial nurture: verified paid conversion, with activation reported separately;
• billing recovery: renewal after a billing issue;
• cancellation: uncancellation or useful feedback, depending on the flow's purpose;
• win-back: verified paid access restored after expiration.

Notification opens and taps explain the route. They are not substitutes for these events. App stores and billing systems can change subscription state without a push interaction, so avoid claiming causal lift from a simple before-and-after report. Use a stable holdout when volume supports one.

Automation is a state machine with copy attached

The strongest RevenueCat push automation is small enough to reason about. It starts on a verified server event, tells the truth about that state, stops on every superseding state and sends a person to a destination that can complete the promised action.

Connect the webhook using the RevenueCat + Pushlane integration guide, then ship one blueprint. A five-flow canvas is not progress if none of its exit events have been tested.