Instrument your app
This is the code track. Every step here is code you write once: mount the SDK, tell Schematic which company is active, meter what that company consumes, and enforce what it is entitled to. The plans, features, and allowances themselves are configured in the dashboard and change without a deploy, so nothing below hard-codes a limit or a price.
If the vocabulary is unfamiliar, Concepts defines features, entitlements, companies, and flags. The examples below use @schematichq/schematic-react. The same five moves exist in every SDK, listed in the SDK overview.
What you need first
- A Schematic account and a publishable key from Settings, API Keys.
- At least one feature with a flag key. If nobody has created one yet, either run through Set up your first plan or click Generate Sample Data on the Quickstart page in the app.
1. Install and mount the SDK
Wrap your application in SchematicProvider so every hook below has a client to talk to.
Full install and configuration details, including the provider options, are on Install the SDK.
2. Identify the company and user
Schematic resolves entitlements per company, so nothing works until the SDK knows which company is signed in. Call identify once when your session is established.
The keys are your identifiers, not ours. Use whatever you already have, such as your internal account ID or a Stripe customer ID. Identify users and companies covers traits, the server-side upsertCompany equivalent, and when to reach for each.
3. Check an entitlement
useSchematicEntitlement reads like a feature flag. Ask whether the current company has access and render accordingly.
The string is the flag key set on the feature in the dashboard. Whether that flag resolves true depends on the company’s plan, any overrides, and any trial, and none of that logic lives in your codebase.
4. Send usage events
For metered features, the same hook returns the allowance and the usage so far, and useSchematicEvents gives you track to report each use.
track is fire and forget on the client. Report the same event from your backend instead when the action can happen outside a browser session, or when you cannot trust the client to report honestly. See usage-based billing for how allowances, overages, and resets are configured.
5. Render a component
Components such as the Customer Portal and Checkout are configured in the dashboard and dropped into your app by ID. Because they let a customer change their own billing, rendering one needs a temporary access token scoped to a single company, and that token requires a secret key. Issue it on your server and never ship the secret key to the client.
Pass that token to the embed alongside the component ID. The Components docs cover mounting, theming, and the full set of templates.
Verify it worked
- The Companies tab lists the company you identified, with a last seen timestamp that updates on every
identifyortrackcall. - The Events tab shows each event as it arrives, which is the fastest way to confirm your flag key and event name match what the dashboard expects.
- Flipping an entitlement in the dashboard changes what your app renders on the next check, with no deploy.
What’s next
The other track. The dashboard side of the same setup, for whoever owns pricing and packaging.
Plain-language definitions of features, plans, entitlements, and companies.
Go deeper on the parts you touched:
- Key management — how company and user keys resolve, and how to pick them.
- SDKs — the same five moves in Go, Python, Node, Java, Ruby, and C#.
- Components — checkout, meters, and paywalls beyond the Customer Portal.
- Stripe integration — sync plans, subscriptions, and invoices both directions.
- Feature analytics — read the events you are now sending.