Skip to content
OclavexOclavex Docs

Model products & features

The catalog is where you describe what you sell. A product carries the features you license; a version lets it evolve without disturbing live customers. This all lives under the Catalog group.

Create a product

Section titled “Create a product”

Under Catalog → Products, create a product and give it a name, a code and a version. The code is the stable identifier your integration and API use; the version lets you ship changes deliberately (see Version it below).

A product moves through a lifecycle — keep it in draft while you model it, then publish it when it is ready to sell.

Define features

Section titled “Define features”

Features are the capabilities you license — each has a dotted code like api-calls.total or export.enabled. Define them once and reuse them.

  • Feature Catalog (Catalog → Feature Catalog, or the product’s Feature catalog tab) — the definitions: a code, a display name, a data type (Boolean, Numeric, Text, Enumeration, Metered or JsonField) and, for numeric features, a unit.
  • Product Features (the product’s Features in this version tab) — which catalog features this product offers, and their default values.

Defining a feature in the catalog doesn’t grant anything on its own — it becomes real when a plan sets its value and an entitlement grants it.

Set up monitored assets

Section titled “Set up monitored assets”

For anything you want to count — API calls, exports, render minutes — use the product’s Metering & monitoring tab. A monitored asset is the meter behind a numeric feature: it’s what usage is reported against and what a plan’s quotas and credits draw down. See Metering, quotas & credits for how the counting and capping work.

Version it

Section titled “Version it”

When you need to change what a product offers, publish a new version rather than editing the live one. Two things make this safe:

  • Features are copied at grant. When a product is added to an entitlement, its features are copied in, so later edits never silently change a live customer’s grant.
  • Plans belong to the suite. A plan set is scoped to the product’s suite rather than to one version. If a new version’s pricing must not disturb the previous one, give it its own suite — or its own plan set on that suite.

Duplicating a product as a new version copies its features and usage plans. Metrics, monitored assets and product properties are not copied — set those up again on the new version before you publish it.

So the clean pattern is: create a new version, give it its plan set, and grant new entitlements against it — existing customers keep what they had until you renew or migrate them.

A product won’t publish while any of its features is still Draft in the feature catalog — publish the catalog entries first.

Next

Section titled “Next”