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 authored presentation that the SDK selects locally: 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> options.user. 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

Local decisions, explicit delivery policy

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. Hosted loading and refresh can fail; choose an explicit freshness and failure policy for the snapshot your app evaluates.

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>)
User	An application-identified person; user.id is distinct from their account
Account	An organization or billing scope identified by account_id; membership is enforced by your app
Trigger	A supported event or condition that makes a placement eligible for consideration

“Moment” can describe when your app asks for a decision, but SDK 0.12.4 has no public moment() function. Use the documented trigger, Gate, Slot, and headless APIs. Likewise, proposed InlineSlot/OverlaySlot names are not current exports. A slot is a place to render; an overlay is a presentation choice of the selected component/template, not a separate SDK decision service.

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