Skip to main content

Documentation Index

Fetch the complete documentation index at: https://recurr.dev/docs/llms.txt

Use this file to discover all available pages before exploring further.

The most common conversion drop in any migration flow is the moment a subscriber is asked to “create a password.” Migration sidesteps this by carrying identity forward — if they signed in with Apple in-app, they sign in with Apple on web.

​
Why this matters

A subscriber on the migration email link arrives on web with a single goal: confirm the migration and keep their subscription active. Anything between them and that confirmation step is a churn risk. “Create a password and verify your email” is the highest-friction interruption available. Even with the right copy and a recovery flow, a non-trivial fraction of subscribers will close the tab. The framework removes that step entirely for the majority of subscribers — they tap “Sign in with Apple,” authorize, and the migration completes.

​
Supported providers

Apple Sign In

First-class on web checkout. Recognizes the same Apple ID the subscriber used in-app, including private-relay email addresses.

Google Sign In

First-class on web checkout. Same Google account they signed in with on Android (or iOS, if they used Google Sign In there).

Email magic link

Fallback for subscribers without OAuth identity. The framework sends a one-time login link to the email on file; one tap from inbox to authenticated session.

Email + password

Available but de-emphasized. Used only when none of the above are configured for the subscriber’s account.

​
Mapping identity to subscription

The migration framework tracks the subscriber identity across rails:
  • In-app identity (Apple ID, Google account, or your app’s auth) is recorded against the IAP subscription
  • Web identity (whichever provider they used at checkout) is mapped to the same canonical subscriber record
  • Webhook back to your entitlement system carries the canonical subscriber ID, so your app’s existing identity model continues to work
If a subscriber chose a different provider on web than they used in-app (e.g., Apple in-app, Google on web), the framework recognizes the migration via the email link’s hash and writes the entitlement under the canonical record. The subscriber doesn’t see the cross-mapping; their app just continues to work.

​
Apple Sign In + private relay

Apple Sign In’s private-relay email addresses (xyz@privaterelay.appleid.com) are fully supported:
  • The framework can email subscribers at the relay address; Apple forwards
  • The relay address is stable per-subscriber, so it works as the canonical identifier
  • Subscribers can revoke private-relay forwarding from Apple, in which case the email becomes undeliverable; this is rare and the framework flags it for the support flow

​
What the app team doesn’t have to do

  • No new auth flow in the app
  • No password reset / account recovery wiring
  • No identity-merge logic in your backend
  • No OAuth client registrations on your side (the framework’s OAuth apps are used)
Pilot reservation →