SubKit owns versioned products and offerings, normalized subscriptions, purchases, contracts and payments, distributable access capacity, invitation reservations, allocations, and the resulting app-user or organization entitlements. Apple, Google, and payment providers feed SubKit through verified inputs — they never hold a competing license state.
Pick your path
Build a mobile app
Integrate purchases and access in Expo / React Native with the @piparotech/subkit-expo SDK.
Render offerings, run purchases, and gate features on entitlements. Start
here
Build a backend
Drive commerce and access from trusted server code with @piparotech/subkit-node: customers,
contracts, payments, seats, and entitlement checks. Start here
Operate the platform
Connect stores, manage the catalog, and go live safely with verified reads and confirmed writes. Store setup
The one rule that shapes everything
App code never asks “does this user have a subscription or license?” It asks “does this access subject have this entitlement?” Every cause of access — free enrollment, store subscription, purchase, contract, trial, promotion, or manual provision — resolves through the same path:
Access Source → Access Pool → Reservation/Allocation → Entitlement GrantRead Access model to understand why this keeps app logic stable across single subscriptions, club seats, and every commerce cause.
Architecture in one minute
Mobile apps use the Runtime API with public, app-bound keys. Trusted backends and operators use the capability-scoped Server API. Both meet the same canonical Catalog, Commerce, and Access domains. Store and payment systems remain outside that boundary: adapters verify their evidence, then SubKit persists normalized Sources and derives Pools, Allocations, and Grants. No consumer or provider maintains a parallel license truth.
Built for machines too
Every page is available as clean Markdown, and SubKit publishes curated
/llms.txt context files so coding
agents can load the smallest useful context instead of scraping HTML.