Streaming clients and the self-hosted Replicator hold a local copy of entitlement state, so flag checks run in memory with no call to Schematic in the request path. If that connection drops during a deploy or a network interruption, the client resumes where it left off and replays only the updates it missed, instead of tearing down and re-syncing the entire dataset.

Local state stays current, enforcement keeps running without a gap, and reconnects stop triggering a cold re-sync. This matters most for high-throughput deployments that run on local state and cannot absorb a resync stall on every reconnect.

A catalog is a complete set of plans, add-ons, credits, and components with its own configuration. An account used to have exactly one. Multi-catalog lets you run several side by side, so you can offer different packaging and pricing to different audiences without standing up separate accounts. Use it for region or currency-specific pricing, for separate brands or business units, or for a self-serve catalog running alongside a sales-led one.

A company can hold plans in more than one catalog at the same time, each with its own subscription and billing cycle. Existing accounts are unaffected. Single-catalog accounts and their current API calls keep working with no change, and multi-catalog accounts pass a catalog ID on entitlement checks to resolve the right plan.

Billing entities separate who pays from who uses the product. Designate a company as a billing entity and it pays the subscriptions of every company associated with it, on one combined invoice, with one payment method. The associated companies keep their own plans, entitlements, usage, and limits, and manage their own plan. Only the billing entity is a customer in your billing provider, so the accounts consuming the product do not each need a card on file.

This handles the cases where the buyer and the user are not the same account: a parent company paying for its subsidiaries, or an agency buying on behalf of its clients. Assign a billing entity through the company upsert, provision parent and child accounts together, and import existing multi-subscription Stripe customers with the association preserved.

Idempotency keys

The create-event endpoint now accepts an optional idempotency_key. When two events arrive with the same key, the second is treated as a duplicate and dropped instead of recorded again. This makes event submission safe to retry after a timeout or network failure without double-counting usage or burning credits twice. The key is optional, so existing integrations keep working unchanged.

Historical event timestamps

Two new optional fields on the track endpoint let you control an event's effective timestamp instead of using server receipt time. Both require a secret API key. trusted_client_clock uses your sent_at value as the event time and still runs all billing: credits are consumed, Stripe meter events report at the logical time, and usage webhooks fire.

Use it to correct recent usage, within 5 minutes ahead and 34 days back. backfill is analytics-only. Events land at their logical time but skip every billing side effect, including credit consumption, Stripe reporting, usage webhooks, auto top-up, and last-seen updates. Use it to import historical usage up to 365 days back. ClickHouse event retention moved from 60 to 365 days to match.

The company profile is rebuilt as one scrolling page with a fixed left sidebar and a submenu that anchors to each section. Plan, subscription total, next bill date, trial status, and the Manage Plan button now sit in the sidebar where they stay visible. Usage and limits are on the page itself instead of behind a panel you have to open. IDs copy on click. The page loads progressively so the most important information appears first.

Schematic checkout previously collected only billing email, address, and phone. You can now define custom fields in Checkout Settings, each one mapped to a Stripe customer metadata key, and mark them required. Configured fields appear on every subscription checkout, and their values are written to both the Stripe customer record and the Schematic company record.

Customers can update the values after subscribing: the existing Payment Method component becomes Payment Details and shows each field with an edit modal. This unblocks regional e-invoicing and tax workflows that depend on extra metadata, with no code on your side. Stripe only in this version.

Schematic completed its GDPR compliance requirements. This covers the data processing agreement available to customers, an appointed EU representative, cookie consent, executed vendor DPAs, and data breach, privacy, and information security policies, tracked through Vanta. This sits alongside the existing record deletion and anonymization endpoints that let you erase company and user data on request.

Moving companies between plan versions previously required going through the version-creation flow, which could strand an account if the destination version had not been created yet.

You can now start a migration directly from the Plans page or a plan version's menu, pick any destination version, and pull companies from one or more origin versions. This removes the dependency on the versioning flow and fixes the case where a customer could not migrate because they could not create the target version first.