Skip to main content
Features describe what each plan offers. You define a feature once for the app, then include it in as many plans as you like with a value per plan. That’s how a plan says “this tier gets advanced reports” or “this tier is capped at 5 seats”.

​
Defining one

The key and type are immutable because your code already gates on them and values are stored per type. The name and description are yours to rewrite whenever: they’re marketing copy, not contracts. The features list is searchable by name or key. Global search ranks an exact key match first, which is useful when you are debugging isEnabled("<key>").

​
Features and plans

The link is many-to-many with a value per plan: a plan includes many features, and a feature appears in many plans, each with its own value. A boolean feature is simply in or out of a plan; a number feature carries that plan’s limit. Set which features a plan includes, and their values, when you create the plan. Deleting a feature removes it from every plan that includes it.

​
Gating in your app

Your app reads features through the SDK: featureEnabled(key) for a boolean, featureLimit(key) for a number. The feature page shows the exact snippet for the feature you’re looking at, so the key you gate on is copied, not retyped. Three things worth knowing about gating:
  • A key your app checks that doesn’t exist resolves to not enabled: a typo silently gates nothing off, which is why the snippet exists.
  • Entitlements resolve through one path everywhere, so a gate behaves the same in your app, in the SDK, and in an agent reading Meridian MCP.
  • A merchant who upgrades gets the new values immediately; there’s nothing to sync on your side.
Features are about what a plan includes, not about metering. If the thing you want to charge for is a count that goes up with use, it’s an event, not a number feature.
Last modified on September 29, 2026