RevenueCat + Pushlane: Turn Subscription Events into Push Flows

If your app runs on RevenueCat, every subscription moment you care about already exists as a webhook: trials starting, trials converting, cards failing, subscribers turning off auto renew. Most teams let those webhooks pile up in a Slack channel or a database table nobody queries. This guide wires them into something more useful: push notification flows that react to each lifecycle event, built in Pushlane's visual builder, with zero purchase tracking code added to your app.

The whole setup is a webhook in the RevenueCat dashboard plus one identity convention in your client code. If you already call Purchases.logIn() with a stable user id, you are most of the way there.

What the integration actually does

RevenueCat knows every subscription lifecycle moment in your app because it processes the receipts. When you connect its webhooks to Pushlane, each of those moments arrives as an event attached to the right user, and any event in Pushlane can trigger a flow.

The events you get:

• revenuecat.trial_started: a user began a free trial
• revenuecat.trial_converted: a trial turned into a paid subscription
• revenuecat.trial_cancelled: a user cancelled during the trial
• revenuecat.renewal: a paid subscription renewed
• revenuecat.billing_issue: a renewal payment failed
• revenuecat.cancellation: a subscriber turned off auto renew (access continues until the period ends)
• revenuecat.expiration: access actually ended

Notice what is missing from this list: client code. You never write a "track trial started" call in the app. There is no purchase tracking logic to keep in sync with your paywall, and no risk of a client claiming a purchase that the store later refuses. The webhook comes from RevenueCat's servers, which are the source of truth for subscription state, and Pushlane treats it exactly like any other event: something a flow can trigger on, wait for, or branch on.

If you want the strategy layer (which lifecycle moments deserve a push at all, and which should stay silent), read push notifications for subscription apps. This article stays on the plumbing.

Why it works: one shared user id

A RevenueCat webhook identifies the customer by app user id. A push token in Pushlane belongs to a device that called identify() with a user id. If those two ids are the same string, the event lands on the right person and the flow can send. If they differ, the event is an orphan and nothing happens.

So the entire integration rests on one convention:

// The same id goes to both SDKs. That is the whole trick.
Purchases.shared.logIn(userId)   // RevenueCat
Pushlane.identify(userId)        // Pushlane

Two common situations:

• Your app has accounts. Log both SDKs in with your backend user id. Done.
• Your app is anonymous. RevenueCat generates an anonymous app user id on first launch. Read it back from the SDK and pass that same value to Pushlane's identify call, so both systems share RevenueCat's id.

RevenueCat's documentation on app user ids covers the id modes in detail. The exact identify syntax for each platform is in the Pushlane quickstarts: iOS, Expo, React Native, Flutter and Android.

There is no mapping table to maintain and no id translation service to build. Matching ids in, matched events out.

Step by step setup

Four steps, and only the first one touches your codebase.

1. Install the Pushlane SDK and identify users

On iOS, the SDK installs through Swift Package Manager (iOS quickstart, API reference in /docs/ios-sdk). For Expo, React Native, Flutter and Android, Pushlane uses zero dependency drop-in clients: one file you paste into your project, no npm package or Gradle dependency to add. It reuses the notification libraries your project already has.

If you work with an AI coding agent, Pushlane also exposes an MCP server that walks the agent through install, event instrumentation and this exact RevenueCat wiring, so the whole setup can be agent-driven.

Whichever path you take, make sure identify() is called with the shared user id from the section above, and that your app requests push permission at a sensible moment.

2. Copy your webhook URL and secret from Pushlane

In the Pushlane dashboard, open the RevenueCat integration page. It gives you two values: a webhook URL for your app, and a webhook secret. The secret is what you will paste into RevenueCat's Authorization header field, and it is how Pushlane verifies that each incoming webhook really came from your RevenueCat project rather than from anyone who found the URL. The current dashboard walkthrough with screenshots lives at /docs/revenuecat.

One thing to get right: the webhook secret is its own value. Do not paste a Pushlane write key (the lpk_ prefixed key your SDK uses) into the RevenueCat field. Pushlane rejects write keys on the webhook endpoint on purpose, because write keys ship inside your app binary and should never act as a webhook credential.

3. Create the webhook in the RevenueCat dashboard

In RevenueCat: open your project, go to Integrations, then Webhooks, and add a new webhook.

• URL: the webhook URL you copied from Pushlane
• Authorization header: the secret you copied from Pushlane
• Event types: leave the default (all events); Pushlane simply ignores anything it does not map

RevenueCat's official webhook documentation describes every dashboard field and the full payload format, which is worth skimming once so you know what is actually being sent.

Save it. From this moment, subscription events start flowing.

4. Verify events arrive

Do not skip this step. Trigger a sandbox purchase from a development build (starting a trial is the easiest), then check the events log in Pushlane. You should see revenuecat.trial_started attached to the exact user id you identified with. The /docs/events page shows where the log lives and what you can filter on.

RevenueCat's webhook page shows delivery attempts and response codes on its side, so debugging is a two-screen job. Two failure modes cover almost every problem:

• RevenueCat shows the webhook fired, Pushlane rejected it. The Authorization secret does not match. Re-copy it from the integration page.
• The event arrived, but on an unknown user. The app user id RevenueCat sent does not equal the id you passed to identify(). Fix the id convention and test again. This is the single most common setup mistake, and it is always an id mismatch, not a Pushlane or RevenueCat bug.

5. Build a flow on the trigger

In the visual flow builder, create a new flow and pick a RevenueCat event as the entry trigger. From there you compose the flow like any other: push steps, wait steps, branches, exits. You can start from a flow template instead of a blank canvas, generate push copy with AI, and narrow the entry with audience segments (for example, only users on a specific plan). The builder reference is at /docs/building-flows.

Sending is consent-aware by default: a user who opted out of push is suppressed, not messaged. You do not need to build that check into the flow.

Activate the flow, run one more sandbox event, and watch it enter. That is the full loop: RevenueCat webhook in, push out, no app release required.

Three flows worth building first

You could build a flow per event, but three of them earn their keep before anything else.

1. Billing issue recovery

Trigger: revenuecat.billing_issue.

When a renewal charge fails, the store retries the payment for a grace window, and during that window the user usually has no idea anything is wrong. A push is the honest, useful intervention: the user wants to keep the thing they are paying for, and the fix takes a minute.

Your payment did not go through. Update your card in the next few days to keep your Premium access.

A solid shape for this flow: send the first push shortly after the event, wait two days, send one reminder, and exit early if a revenuecat.renewal event arrives in the meantime (the retry succeeded, stop talking about it). Whether this recovers a little or a lot of revenue depends entirely on your audience and price point: measure it in your app rather than trusting anyone's benchmark.

2. Trial nurture that ends before the charge

Trigger: revenuecat.trial_started.

The trial is a window with a hard deadline, which makes it perfect flow material: a sequence of pushes spaced across the trial days, each pointing at the value the user has not discovered yet, with a clear heads-up before the trial converts. Exit the flow the moment revenuecat.trial_converted or revenuecat.trial_cancelled arrives, so nobody gets a "your trial is ending" push after they already decided.

We wrote up the full sequence design in the trial-to-paid push sequence, and the deadline mechanics specifically in trial expiry push notifications. Both map directly onto this trigger.

3. Cancellation save

Trigger: revenuecat.cancellation.

Cancellation in RevenueCat means auto renew was turned off, not that access ended. The user still has the product until the period expires, which gives you a window to make a case while they can still change their mind with one tap. Keep it to a single push, and keep the tone honest: no guilt, no dark patterns.

You still have Premium until March 12. If something was not working for you, reply in the app and tell us. If you change your mind, resubscribing takes one tap.

Pair it with a quieter follow-up on revenuecat.expiration for the users who let it lapse. For the complete lifecycle map (which flows connect to which events, and how they hand off to each other), see subscription push notification flows.

Once any of these is live, the next lever is copy: Pushlane supports A/B testing inside flows, so you can test two variants of the billing push against each other on real traffic. How to structure those tests is covered in push notification A/B testing for subscription apps.

A note on delivery honesty

Pushlane is push-only, for mobile apps. On iOS, delivery goes through APNs (Apple's push service, documented under UserNotifications) and is proven end to end: event in, APNs accepts, notification lands on the device. On Android, the drop-in client registers FCM tokens, but we do not claim proven end-to-end Android delivery today. If your app is Android-first, know that before you build your lifecycle messaging on top of this; if you are iOS-first or iOS-only, the path is solid.

APNs credentials are per app: you upload your own .p8 key, and Pushlane will never report a send as delivered when it could not actually reach Apple. Setup is at /docs/apns-setup.

Start free

The honest pitch for this integration is subtraction. You delete the idea of writing purchase tracking code, you delete the cron job that would have polled subscription state, and you replace both with one webhook and one shared user id. RevenueCat already emits the events; Pushlane just makes them actionable.

Pushlane has a free tier, so you can wire the webhook, verify events with a sandbox purchase, and ship the billing issue flow without paying anything. Start at https://pushlane.io, follow /docs/revenuecat, and build the recovery flow first: it is the one that pays for the rest.