Licenses, add-ons, prices and vouchers: four primitives that turn your commercial contracts into infrastructure rules. Versioned licenses and the entitlements they grant run today. Add-ons, prices and vouchers — including vouchers that grant a feature flag — are on the roadmap, and billing stays provider-agnostic by design.
The Problem
Every B2B SaaS ends up having the same conversation: "We need to let the AE grant a temporary Pro access." Then: "+2 extra seats for this deal." Then: "Turn on the beta dashboard for Acme for 6 months." Three tickets, three deploys, three ways to break production.
if (plan === 'enterprise') scattered across your codebase. Every pricing change requires a deploy. Every negotiated contract becomes a code exception.
A billing coupon gives you -20%. It can't grant 500 extra API calls. It can't turn on a feature flag. So your team writes custom code for every negotiated deal.
Entitlements tied to one billing provider make every provider change a rewrite of your monetization stack. You're paying for lock-in, not flexibility.
The Kaiten Way
Kaiten's licensing model is built into the control plane — not bolted on. Licenses ship today: versioned, audited, and queryable through the API, the SDKs and the MCP server. Add-ons, prices and vouchers are on the roadmap, on the same model.
The Kaiten plan
The commercial contract as code, and it ships today. Types: DEVELOPMENT, TRIAL, PAID, COMMUNITY. Each license is a numbered version of a product: publish a new version and existing customers stay on theirs until you move them. Grants entitlements — on/off features, quotas, AI credits and JSON config.
Modular extensions
On the roadmap: add-ons mirror the license structure and attach to a license at subscription time, with their own entitlements and prices. An override_behavior (ADD, OVERRIDE, MAX) will decide how an add-on's quotas combine with the base license — "+5000 API calls" ADDs, "unlimited API calls" OVERRIDEs.
6 billing models
On the roadmap: native pricing with six billing models — flat fee, usage-based, pay-in-advance, overage, tiered, graduated. Each price will link to a provider price through billing_provider_id + external_id, or be declared natively, and one license will carry several (monthly and annual).
Beyond coupons
On the roadmap: four types — PRICE (discount), ENTITLEMENT_BOOST (modify quotas), FLAG_GRANT (activate a feature flag), COMPOSITE (combine all three). One voucher will act on price, quotas and flags at once, so Sales can negotiate a whole deal package in one instrument.
Voucher Types
On the roadmap: a voucher that acts on three dimensions at once — price, entitlement limits and feature flag access. One code will replace three tickets.
Percentage or fixed amount off the price. Duration: one-time, repeating for N periods, or forever. Links to a provider coupon (stripe_coupon_id) or is declared natively.
Example
Multiply, add, set, or lift the limit on an entitlement value for a duration. Perfect for onboarding: give 2x quotas for the first 3 months to reduce activation friction.
Example
Temporarily turn on a feature flag for a customer — without reassigning them to a different plan. Ideal for beta access, Sales-negotiated early access, or support overrides.
Example
Combine the three. For enterprise negotiations: "-30% + quotas ×2 + white-label flag on for 12 months." One voucher code, full audit trail, clean lifecycle.
Example
Kaiten doesn't replace your billing engine — it feeds it. Today the seam is the event stream: every accepted usage report and every license change commits an event through the transactional outbox, and a consumer you write feeds your billing provider from it. Native billing adapters are on the roadmap: they will make the provider a configuration choice rather than a consumer you write.
The direction is provider-agnostic by design: one canonical event model, so a webhook from Stripe or Lago will land in the same shape, and switching providers will be a configuration change rather than a code migration.
Consume the event stream today · Native billing with Stripe and Lago on the roadmap
Kaiten Licensing Model
Licenses · Add-ons · Prices · Vouchers
React SDK
Prebuilt React components for pricing tables, customer portals, usage meters and paywalls, on a headless core you can also use alone. The paywall checks an entitlement and a feature flag in one gate.
@kaitencloud/react-ui draws the components — PricingTable, CustomerPortal, UsageMeters, Paywall, PlanBadge and more — with every style scoped under one root, so none of it reaches the rest of your app. @kaitencloud/react is the headless core underneath: the provider, the hooks and a Gate, for teams who draw in their own design system.
Signed in, the provider reads one customer's plan, entitlements, usage and flags from your Kaiten API, and reads them again every five minutes. A pricing page renders from a plan catalog you supply, with no key and no request. Both packages are on the roadmap.
React components on the roadmap · Vue, Svelte and Angular after them
import { KaitenProvider, KaitenStyleRoot, Paywall }
from "@kaitencloud/react-ui";
import "@kaitencloud/react-ui/styles.css";
function App() {
return (
<KaitenProvider
mode="authenticated"
apiUrl="https://app.kaiten.sh/api"
accessToken={getSessionToken} // called on every request
customerId="cust_123"
instanceId="inst_456"
>
<KaitenStyleRoot>
{/* One gate: the entitlement's usage AND the flag */}
<Paywall
entitlement="api-calls"
flagKey="premium-feature"
threshold={0.8}
onUpgrade={(action) => openUpgrade(action?.type)}
>
<ApiPlayground />
</Paywall>
</KaitenStyleRoot>
</KaitenProvider>
);
}import { KaitenProvider, KaitenStyleRoot, Paywall }
from "@kaitencloud/react-ui";
import "@kaitencloud/react-ui/styles.css";
function App() {
return (
<KaitenProvider
mode="authenticated"
apiUrl="https://app.kaiten.sh/api"
accessToken={getSessionToken} // called on every request
customerId="cust_123"
instanceId="inst_456"
>
<KaitenStyleRoot>
{/* One gate: the entitlement's usage AND the flag */}
<Paywall
entitlement="api-calls"
flagKey="premium-feature"
threshold={0.8}
onUpgrade={(action) => openUpgrade(action?.type)}
>
<ApiPlayground />
</Paywall>
</KaitenStyleRoot>
</KaitenProvider>
);
}Domain Events
Licenses and their families emit 12 of the 55 event types Kaiten publishes as webhook contracts, and usage reports emit the signals billing listens to. Each event is committed through a transactional outbox, in the same transaction as the change, then carried by the event pipeline to the audit trail and, on Kaiten Cloud, to your webhook endpoints.
| Event name | Description | Type |
|---|---|---|
| LICENSE_ | New license created | create |
| LICENSE_ | License details updated | update |
| LICENSE_ | License deleted | delete |
| LICENSE_ | License version published | lifecycle |
| LICENSE_ | License version archived; instances on it keep it | lifecycle |
| LICENSE_ | Archived license version back in use | lifecycle |
| LICENSE_ | A product opened by its first version | create |
| LICENSE_ | The version a product serves changed | update |
| LICENSE_ | A product closed with its last version | delete |
| LICENSE_ | Entitlement granted by a license | assign |
| LICENSE_ | Grant's value or overage allowance changed | update |
| LICENSE_ | Entitlement no longer granted by a license | unassign |
| INSTANCE_ | Usage crossed the entitlement's early-warning percentage | usage |
| INSTANCE_ | Usage went past a soft-limit grant, within its allowance | usage |
| ENTITLEMENT_ | Usage report recorded, overage included | usage |
| ENTITLEMENT_ | Usage report refused with a 409; usage left unchanged | usage |
The 16 events above are 16 of the 55 webhook contracts. The other 39, and the payload schema of every one, are in the OpenAPI document. See the full API reference.
Licenses and the entitlements they grant are in the open-source engine and in every Kaiten Cloud tier — Kaiten Cloud is in private beta.