OpenRevKit: Entitlement-Centric Subscriptions, Open Source

Every subscription platform starts the same way. There is one product, one price, two tiers, and a client SDK call that looks like if (user.hasPurchased("pro_monthly_4_99")). It works. It ships. The app launches.

Then a year passes. Someone runs an A/B test that needs a new price point. Pro becomes Pro Plus. The 4.99 becomes 5.99 in some regions, 7.99 in others. A localised SKU gets added, then three more. The hasPurchased("pro_monthly_4_99") check in the client code now has seven cousins, none of which the iOS team wants to deploy a new binary for.

That is how subscription codebases rot. Not from bugs; from accretion. The SKU was meant to be a deployment artifact; it became the contract.

OpenRevKit starts from a different place.

Entitlement-centric SDKs

Entitlement-centric SDKs branch on what a customer is allowed to do, not which SKU they bought. The client call looks like if (user.canAccess("pro_features")). The mapping from SKUs to entitlements lives on the server, versioned and revisable without touching the shipped binary.

The distinction is mechanical but the consequences are architectural. When pricing changes, the server’s SKU-to-entitlement map changes, and every client — including the iOS binary shipped eighteen months ago — picks up the new behaviour. When a new region launches with localised SKUs, the map gains five rows. The client code is identical.

This is the one design decision that keeps subscription code readable five years in.

What OpenRevKit covers

OpenRevKit is a subscription and entitlements platform. It covers the end-to-end lifecycle: purchase, receipt validation, entitlement resolution, webhook reconciliation, and the analytics surface operators need to answer “how many of this entitlement are active and for how long.”

Supported stores

Every store is a first-class integration, not a shim:

• Apple App Store — StoreKit 2, subscription groups, intro offers, family sharing, promotional offers.
• Google Play Billing — Play Billing 6, base plans and offers, prorated upgrades, regional pricing.
• Stripe — Checkout, Billing, customer portal, tax, invoicing.
• Amazon Appstore — IAP v2, entitlements, subscription management.
• Roku Billing — Roku Pay, subscription lifecycle, regional pricing, free-trial handling.

CTV stores (Roku, Amazon Fire TV) are where most mobile-first platforms break. Their receipt formats are different, their webhook semantics are different, and their refund flows are different in ways that do not translate. OpenRevKit normalises all five into one entitlement model on the server.

Client SDKs

One per platform, each around the same entitlement-centric shape:

• user.canAccess(entitlement) — synchronous check against cached state.
• user.activeEntitlements() — list for rendering UI.
• user.purchase(productId) — store-aware purchase flow.
• user.restore() — cross-device restore with server-side reconciliation.

The SDK is small (under 50 kB per platform post-minification on the relevant targets) because the intelligence lives server-side. Clients are cache-and-branch; the server is where entitlement arithmetic happens.

Self-host or hosted

OpenRevKit ships in two deployment shapes. They are the same code; only the operator is different.

Self-host

The open-source build is what most teams start with. It runs on a Postgres database and a Docker Compose or Kubernetes target. The hard dependencies are:

• Postgres 14+ for the subscription database.
• Object storage (S3, R2, or any S3-compatible) for receipts archive.
• One outbound worker for webhook reconciliation.

That is the full infrastructure. No Redis required. No message queue beyond the worker. The Terraform module in the repo stands up a reference deployment on AWS; the Docker Compose file gets you running on a laptop in ten minutes.

Self-host is the right choice when any of these apply:

• Compliance. Subscription data is a compliance artifact (SOC 2, PCI, data residency, regional hosting requirements). It should not live in a vendor’s database.
• Cost. Per-event billing stops making sense at scale; self-hosting at scale is almost always cheaper than hosted platforms once you cross the mid-market threshold.
• Auditability. The team wants to read the code that decides whether a customer is entitled. Open source makes this trivial.

Hosted

The hosted service is the same codebase, operated by us. It is the right choice when:

• You don’t want to operate billing infrastructure. Subscription billing has a low tolerance for downtime; someone needs to be on-call for the database and the webhook queue. If that someone is not in your plan, hosted solves it.
• You want a managed upgrade path. New stores, new receipt formats, new webhook shapes — we ship them and they flow through to every hosted tenant.
• You’re early-stage. Below a certain volume, the operator overhead of self-hosting is not worth the money saved.

The escape hatch between hosted and self-host is real. The database schema is identical; a pg_dump from hosted imports into self-host and vice versa. You are not locked in either direction.

Practical walkthrough: adding a new pricing tier

Here is what changes in a typical OpenRevKit codebase when the product team adds a new “Pro Plus” tier above Pro.

Server side. Add a new SKU in each store’s console (Apple, Google, Stripe, Amazon, Roku). In the OpenRevKit admin, map each new SKU to the existing pro_features entitlement and to a new pro_plus_features entitlement. Total change: five SKU rows added, one entitlement defined, one mapping row per store. No code deploy.

Client side. If the client needs to render Pro Plus features differently, add if (user.canAccess("pro_plus_features")) where relevant. That is the entirety of the client change. No SKU strings in client code. No re-binary required for the old SKU’s customers, because their pro_features entitlement is unchanged.

Webhook side. Nothing. The normalised webhook bridge resolves store events to entitlement changes by lookup, not by hard-coded SKU.

This is what the architecture buys you. Not a faster launch; a launch that does not require touching eighteen-month-old client code.

What OpenRevKit is not

It is not an analytics platform. The admin surface shows what is happening with entitlements in production — active counts, churn, entitlement-week histograms — but OpenRevKit does not try to be Mixpanel or Amplitude. Export the entitlement events and run analytics where analytics already lives.

It is not a CRM. Customer records live in your app, not in the billing platform. OpenRevKit tracks the contract between a customer and an entitlement; everything else is your concern.

It is not a growth platform. There are no built-in A/B-testing surfaces, no “magic” conversion flows, no paywall builders. When the billing layer is opinionated about growth, the growth experiments leak into the billing code. OpenRevKit is opinionated about billing and uncommitted about growth; that boundary is deliberate.

When to look elsewhere

If your subscription stack is a single Stripe integration, one plan, one platform, and no apps on app stores, OpenRevKit is overkill. Use Stripe directly.

If your team is running ten-plus engineers exclusively on iOS and already has a custom receipt-validation pipeline in production, the cost of migration probably exceeds the benefit of the open-source audit trail. Stay on what you have.

If your pricing is genuinely uniform globally, with no regional SKUs, no localised pricing, and no plan-migration history, the SKU-centric model that came pre-built with RevenueCat or similar will work fine for a long time. The entitlement-centric advantage compounds with pricing complexity.

OpenRevKit exists for the teams that have crossed at least one of those thresholds and noticed the code getting harder to change every quarter.

---

Explore OpenRevKit on the product page — self-host the open-source build, or join the hosted early-access list.

Related reading:

• RevenueCat Alternatives for Self-Hosting Teams (2026) — feature matrix across OpenRevKit, RevenueCat, Adapty, and Glassfy.
• How to Ship Cross-Platform Subscriptions Without SKU Hell — concrete walkthrough.