Core Concepts

RevTurbine has a small vocabulary. Learn three primitives and you can read the rest of the docs.

The three primitives

• Entitlements — who can do what. An entitlement answers “is this user allowed to do X, and how much is left?” Feature access, usage limits, credits, and seats are all entitlements. You check them with can() / checkEntitlement.

• Gates — where your app asks. A gate is the checkpoint in your code or UI where you consult an entitlement before letting something happen — a <Gate> around a subtree, a gate('export', …) around an action, or a bare can() check. Same question, different shapes.

• Placements — what to show when it matters. A placement is the UI the control plane decides to render at the right moment: an upgrade prompt when a gate denies, a “running low” banner near a limit, a trial-ending toast. You render one with a <Slot>.

That’s the whole loop: an entitlement defines the policy, a gate asks the question in your app, and a placement is what RevTurbine shows when the answer should change behavior.

What configures them: the Playbook

All three primitives are driven by your Playbook — the portable config RevTurbine evaluates. It holds the plans, entitlement rules (feature / usage-limit / credits / seats), trials, segments (targeting), and placements. A PM edits the Playbook in the RevTurbine dashboard and republishes; your app code doesn’t change.

User context

RevTurbine decides for a specific user, so you tell it who’s asking: an id, the user’s current plan handle, reported usage, and any custom traits. You set this with rt.identify(userId, { plan_handle, usage, …}) or the <RevTurbineProvider> user prop. Entitlement checks and segment targeting both read from it. The dedicated RevTurbineUserContext guide covers every field, update semantics, and server-derived context.

Runtime modes

The same primitives work whether the SDK reads a Playbook bundled with your app (local mode, local_only), syncs it from RevTurbine (hosted mode, revturbine_server), or syncs it through your own endpoints (custom_endpoints). See Runtime Modes.

Where decisions run

No latency, no dependence on our availability

We add no latency and our availability never affects your product. Decisions never have critical dependence on our servers. The RevTurbine SDK runs inside your app, and on your backend where you verify. It evaluates entitlements and placements locally, as a pure function of your Playbook and the current user context.

We push additional inputs to your local engine: aggregated frequency caps, prioritization scores as available. These are additive; nothing breaks or blocks if not present.

A check that can’t justify a grant returns no access rather than guessing, so a misconfiguration never hands out a paid feature. For the money-safe re-check, see Client vs Server Enforcement.

Glossary

Term	Meaning
Entitlement	What a user is allowed to do / how much is left (feature, usage limit, credits, seats)
Gate	A checkpoint where your app consults an entitlement (<Gate>, gate(), can())
Placement	The UI the decision engine shows at the right moment (rendered by <Slot>)
Playbook	The portable config RevTurbine evaluates (plans, entitlements, segments, placements)
Segment	A named rule over user traits used for targeting and experiments
Slot	The component that renders a placement (<Slot>)

For the component/config name aliases (SurfaceSlotComponent, Playbook, …), see the Recommended API Path.

Related

• Recommended API Path — which call to reach for
• Client vs Server Enforcement — policy vs enforcement
• Entitlements · Placements — the primitives in depth