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.

The entitlement.usage_exceeded webhook event is fired whenever customer's usage of a metered feature exceeds one of the defined thresholds.

We're excited to share that it's now possible to customize the thresholds of the webhook event using no-code. 

To do so, in the Stigg app navigate to Integrations > Webhooks section and select the relevant webhook handler. Under the row of the entitlement.usage_exceeded webhook event click on the "Thresholds" link to view and update the event thresholds.

Note that when a usage measurement exceeds more than one threshold, only one event will be fired based on the highest threshold that was exceeded.

In some cases, especially in B2B SaaS, payment for subscriptions is done via wire transfers. 

Luckily, Stigg allows you generate invoice for subscriptions and mark them as paid after receiving confirmation that the relevant funds have been transferred.

The subscription's invoice, which includes the details required for performing the wire transfer, can be shared with customers via payment link or PDF. Customers can then leverage these details to transfer funds to the relevant bank account.

When payment for the subscription is done via ACH, Stripe will automatically mark the invoice as paid. When payment for the subscription is transferred to a bank account outside of Stripe, the invoice needs to manually be marked as paid, which can be done directly from the Stigg app.

Once the invoice is paid, the subscription in Stigg becomes active and access to the the relevant entitlements is granted.

More details about how subscriptions invoices can be generated in Stigg can be found here.

In some cases, especially in B2B SaaS, the person who pays for SaaS subscription is not always a user of the product.

Luckily, Stigg allows you to request payment for subscriptions using a payment link. 

When payment for the subscription using the payment link succeeds, all subsequent subscription updates can take place in a self-served manner, while still leveraging the payment method that was used to complete the payment 😎.

Payment links also allow customers who leverage spend management platforms such as PayEm and Mesh Payments to subscribe to your product using payment methods that are generated by these platforms.

More details about how payment for subscriptions can be requested via payment link can be found here.

We're excited to announce our native integration with the BigQuery!  🎉

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

The integration with the BigQuery is available as a separate add-on. To access it, please contact Stigg Sales.

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

We've made it easier for customers with a .NET backend to get up and running with Stigg by leveraging the Stigg .NET SDK.

The initial version of the .NET serves as a wrapper around Stigg's GraphQL API - caching, polling or streaming of customer entitlements is not currently supported, but will be available soon.

More details on how Stigg can be integrated into your .NET application can be found here.

We've made provisioning of subscriptions to paid plans more customizable by allowing Stigg app users to override the default charge prices.

This new change allows you to offer customers the same plans using different price points, while still leveraging Stigg for managing the subscription billing.

Overriding the default plan price is possible when provisioning and updating subscriptions in the Stigg app, by hovering on the relevant charges and selecting the "Edit price" action.

When the default plan price is overridden, an proper indication will appear next to the charge's price.

To apply the changes to the subscription, confirm the subscription provisioning.

We've added an ability to easily differentiate between single and multiple add-on types:

1. Single instance add-ons allow only 1 instance of the add-on to be included in customers' subscription. This type is useful for add-ons such as: single sign-on (SSO), premium support, Snowflake integration, etc.
2. Multiple instance add-ons allow multiple instances of the add-on to be included in customers' subscription. This type is useful for add-ons such as: additional API calls, additional credits, etc.

The add-on type can be defined when creating or updating an add-on.