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 integration’s hardest concept up front is also its simplest in implementation: Recurr doesn’t replace your entitlement system. It writes to it.

​
How it works

Your app already has some subscription-active check on startup — most often via RevenueCat, Adapty, or a custom backend. That check stays exactly as it is. Recurr connects to the same system from the back side and writes web-subscription records into it as subscribers migrate. 
┌─────────────────────────┐
│ Your existing flow      │
│                         │
│ App opens → checks      │
│ entitlement system →    │
│ "active subscriber" ✓   │
└─────────────────────────┘
         ▲
         │
         │ both sources write here
         │
┌────────┴────────┐  ┌──────────────┐
│ Apple / Google  │  │ Recurr       │
│ (existing)      │  │ (new web     │
│                 │  │  subs)       │
└─────────────────┘  └──────────────┘
The app’s runtime experience is unchanged. The entitlement check returns “active” whether the user is paying via Apple, Google, or their migrated web subscription.

​
Supported entitlement systems

RevenueCat

OAuth integration. Recurr writes via RevenueCat’s REST API into the subscriber’s entitlement record. Native integration, no schema work on your side.

Adapty

OAuth or API key. Same shape as RevenueCat — Recurr writes web subscription state into Adapty’s record.

Custom backend

API-key or webhook integration into your own subscription state store. The framework is data-shape agnostic; the spec gets confirmed in the Migration Review.

StoreKit-only

Not a current fit unless the app has a backend Recurr can write entitlement state into. Recurr does not currently add a mobile SDK or replace a StoreKit-only entitlement architecture.

​
Webhook flow

Once integrated:
  • Subscribe — subscriber completes web checkout → Recurr writes “active” to your entitlement system
  • Renew — Stripe charge succeeds → Recurr extends the entitlement record
  • Cancel — subscriber cancels → Recurr marks lapse at end-of-period in entitlement record
  • Churn — failed payment / hard decline → Recurr writes “lapsed” after dunning exhausts
Your app’s check at startup continues to read from the same entitlement source it always did.

​
What’s not synced

The entitlement record carries subscription state. It doesn’t replicate:
  • Payment method details — those stay in Stripe Connect, accessible from your Stripe dashboard
  • Customer support tickets — those stay in your existing support stack
  • Usage telemetry — the app’s own analytics continue independently
Recurr’s job is the billing and entitlement glue. Everything else stays where it is. Stripe Connect →