In order to best use Stigg, there are a few core product and pricing model concepts that are important to understand. This guide serves as a central reference for navigating these concepts, connecting both developer documentation and specific API references to programmatically model, manage, and evolve your product catalog, plans, and subscriptions.
A product is the foundational object that defines a product or product-line you offer to your customers. It acts as the entry point for modeling pricing, managing plans, and defining the customer lifecycle. Products control how many active subscriptions a customer can hold—either a single subscription or multiple parallel ones—and determine the default behaviors that govern how customers begin, change, or end their subscription journey. Each product also serves as the context for displaying pricing to users and for enforcing subscription logic through SDKs and APIs. Once a product is created, it becomes the anchor for configuring plans, entitlements, usage charges, and trial behavior—all of which collectively define how your product is packaged and monetized.
Plans define how a product is packaged, priced, and made available to customers over a specific billing interval—such as monthly or annually. Each plan encapsulates a combination of features (called entitlements), pricing logic, and optional free trial behavior. These plans act as subscription templates that customers can activate either through self-serve flows or custom provisioning logic.Plans are always linked to a product and serve as the foundation for your monetization strategy. They determine what customers can access, how they’re billed, and how they interact with the product during onboarding, upgrades, downgrades, and cancellations. Stigg’s versioning and visibility tools allow product and growth teams to make changes to plans—such as modifying prices, updating entitlements, or rolling out new tiers—without engineering support.Stigg supports three types of plans, each suited to a different pricing and delivery model:
Free plans are designed for freemium strategies, offering limited functionality at no cost. They don’t require payment information and often include usage limits to drive upgrades.
Paid plans are fully monetized offerings with fixed or usage-based pricing. These plans support billing periods, charges, minimum spend, and free trial options, and can be connected to external billing providers like Stripe.
Custom plans are flexible templates used for sales-led engagements. They support variable pricing and feature configurations negotiated on a per-customer basis and are typically provisioned manually or via API.
Add-ons allow you to offer separately billable functionality that extends the capabilities of existing paid or custom plans. Unlike plans, add-ons are designed to be modular and composable—customers can purchase them individually or in multiples to enhance their core subscription.Each add-on grants specific functionality defined through entitlements, such as additional usage limits, advanced features, or expanded quotas. These entitlements are additive by default: the total value a customer receives for a feature is the sum of entitlements from both the base plan and any active add-ons. In multi-instance configurations, the entitlements are multiplied by the number of add-on units purchased.Add-ons are fully tied to the lifecycle of the plan they extend. When a customer’s subscription to a plan ends, any associated add-ons are deactivated as well. Add-ons can also define their own pricing, billing periods, visibility, and compatibility rules—providing teams with the flexibility to monetize additional value independently of core plans.Stigg supports two types of add-ons:
Paid add-ons: Designed for self-serve scenarios, paid add-ons include a recurring charge and can be published to appear in customer-facing pricing tables. They support multiple billing intervals and currency localization.
Custom add-ons: Best suited for negotiated or enterprise deals, custom add-ons allow sales teams to define pricing and entitlements on a per-customer basis. These add-ons must be paired with a custom plan and are excluded from automated billing system integrations.
Features in Stigg define the core functionality that your customers can access through their plans and add-ons. They act as entitlements—configurable units of value or capability—that determine what’s available to customers based on their subscription. Stigg supports several feature types, each suited to different use cases, from simple binary access to complex usage tracking and conditional value sets.By assigning features to plans or add-ons, you control the entitlements a customer receives. These features are then surfaced in pricing tables, dashboards, and customer portals using Stigg SDKs and APIs.Stigg supports the following feature types:
Boolean features: Grant or deny access to a capability using a simple on/off switch. Ideal for enabling discrete features like “Premium Support” or “Access to API.”
Configuration features: Assign a numeric value that controls a feature’s behavior—for example, “Number of team members” or “Max projects.”
Metered features: Track usage over time, with optional limits. These are commonly used for usage-based pricing models, such as “API calls per month” or “Messages sent.”
Enum features: A specialized form of configuration feature that allows you to assign one or more values from a predefined list—useful for options like “Supported countries,” “Available templates,” or “Support tier.” These can be managed centrally, overridden by add-ons, and queried programmatically.
Entitlements represent the permissions that define what functionality a customer can access, and to what extent. Unlike simple plan identifiers or feature flags, entitlements decouple your application’s behavior from its pricing model, allowing you to update product access dynamically—without changing code.Each entitlement corresponds to a feature and its configuration, forming the core of Stigg’s monetization engine. These entitlements are assigned to plans and add-ons, and they determine how your product behaves for different customers.
Coupons in Stigg are discount instruments that can be applied to customers or specific subscriptions to reduce their billing amount. Coupons support either percentage-based or fixed-amount discounts and can be configured with a limited or unlimited duration.When applied to a customer, the coupon affects all active subscriptions associated with that customer. When applied to a specific subscription, only that subscription receives the discount.Coupons can be managed centrally within the Product Catalog and support metadata for integration with custom business logic via Stigg’s SDKs, API, and webhooks. When integrated with billing providers (e.g., Stripe), coupon names also appear on customer invoices.
In Stigg, a Customer represents an individual or organization that holds one or more subscriptions and interacts with your product. Each customer has a unique ID (immutable), and optionally a name and email address used for display and billing purposes.
A subscription defines the specific set of functionality a customer has access to, under what terms, for how long, and at what cost. It links a customer to a plan and optional add-ons, and determines the customer’s entitlements, usage limits, and billing behavior. Subscriptions may include trials, discounts, or usage-based charges, and support real-time updates such as upgrades, downgrades, and scheduled changes. Each subscription reflects the current state of the customer’s relationship with your product and is central to how access and pricing are managed in Stigg.
An environment represents an isolated workspace within an account, used to manage and test pricing, packaging, and customer access in different stages of your development lifecycle. Each environment—such as development, staging, or production—maintains separate configurations, data, and API keys. Production environments are used for real customer interactions and are subject to usage limits and SLAs, while non-production environments serve as sandboxes for experimentation without impacting live data. This separation ensures safe iteration and controlled rollout of pricing changes across your software delivery pipeline.
