We've added a new API for listing customers' active subscriptions. The new API is accessible from Edge and has a significantly higher rate limit.

Listing customers' active subscriptions can now be achieved by the getActiveSubscriptionsList method. Getting the full data of each subscription can then be done using the getSubscription method.

The new API is available in the Stigg Node.js SDK v3.37.0, Stigg Python SDK v1.236.0, Stigg Go SDK v1.236.0, Stigg Java SDK v1.236.0, Stigg Ruby SDK v1.236.0, Stigg .NET SDK v.1236.0, Stigg Sidecar SDK v2.0.0, Stigg JavaScript SDK v3.20.0, Stigg React SDK v5.16.0, Stigg Vue.js SDK v4.5.0 and Stigg Embed SDK v5.6.0 or later.

We've extended the Subscription Details screen in the Stigg app to provide visibility for the next estimated bill. 

When clicking on the estimated bill amount, users can view a breakdown of all of the upcoming charges.

Viewing the next estimated bill is especially helpful for products that are monetized via pay-as-you-go and hybrid pricing models.

A common pricing model in SaaS is to offer team plans with separate usage enforcement for each team member. For example, as part of a team plan every team member gets access 100 AI actions per month.

We've made now it easier than ever to implement this pricing model by leveraging Stigg to automatically cancel the team members' subscription when the team subscription is canceled.

More details about this pricing model and how model it in Stigg can be found here.

Every event on the Stigg platform is audited, and visibility for these events is available via the Activity Log. 

Using the Activity Log users can answer the following questions:

1. What happened?

2. When did it happen?

3. Who (or what) triggered the event?

Thus, the Activity Log serves as an audit log for actions on the Stigg platform and can also be useful for troubleshooting.

The Stigg app includes both a general activity log with all of the events of a specific environment, as well as an entity-specific log with a pre-filtered list of events for that entity. Event are also accessible via API.

The Activity Log is available in beta for customers on the Stigg Growth plan or higher, and currently includes events from May 22nd, 2024 or later.

More details about the Activity Log can be found here.

Stigg allows you to report usage in a high granularity (for example: bytes) and present it customers in a different granularity (for example: GB).

When this configuration is enabled, even though the usage is reported in the higher granularity (i.e. bytes), throughout the Stigg app and SDK methods the units will be returned in the lower granularity (i.e. GB).

When integrated with a billing solution, the lower granularity units (i.e. GB) will be rounded up to the nearest integer. This means that if a customer is paying per used GB and has used 0.02 GB, they'll be billed for 1 GB.

To enable this configuration, toggle on the "Feature is sold in different units" configuration, define the units that will be presented to customers and the conversion rate between the reporting units and presented units, for example: 1 GB = 1,000,000,000 bytes.

More details can be found here.

We're excited to share that our native integration with Snowflake is now generally available! 🎉

With this integration customers can sync raw data from Stigg into Snowflake, enabling the creation of customized reports and fostering informed business decision-making.

The Snowflake integration is included in the Stigg Scale plan, and can also purchased as an annual add-on for the Growth plan.

More details about the integration and available data types can be found in our docs.

Stigg allows you to easily add checkout experiences to your application using an embeddable checkout widget.

In this flow, the Stigg frontend SDKs can initiate a checkout session directly against the Stigg backend; thus, saving you the need to create a dedicated "checkout" endpoint in your backend. 

Consequently, this means that the Stigg frontend SDKs can perform write operations in the Stigg platform.

When stricter access is required, it's possible to limit the frontend SDKs to read-only access. 

Doing is possible by leveraging Stigg's client-side hardening implementation and adding a ro: prefix to the generated customer token.

More details can be found here.

We've extended the Stigg app to allow grouping of historical usage of event-based metered features according to reported event dimensions. This new feature allows you to see customers' usage broken down into different dimension values.

To do so, under the Entitlement Usage section select the event-based metered feature that you'd like to inspect its usage and the event dimension that you'd like to group the meter usage by:

We've improved the user experience for adding and updating plan and add-on entitlements! 🤩

Adding entitlements now takes place via side panel and includes a clearer path for adding multiple entitlements at the same time.

Once confirmed, the update takes place in the background and no longer causes a refresh of the entire screen.

Add-ons in Stigg represent separately billable functionality that extends plans.

By default, add-on entitlements increase the plan limit, for example: if a plan includes access to 10 seats, purchasing an add-on for 20 seats would result in a seat limit of 10 + 20 = 30 seats; however, there are cases where vendors would like the add-on entitlement to override the plan limit.

We've now added the ability to control this configuration using no-code. The configuration can be defined separately for each of the add-on's entitlements.

When adding an entitlement to an add-on or updating an existing one you can specify the entitlement behavior - whether to increment the plan limit or override it.

More details can be found here.