We've updated the behavior when publishing changes to plans an add-ons:

1. By default, pricing changes are only applied to new subscriptions.

2. All other changes can be applied both to new and existing subscriptions; however, they will not affect the pricing of existing subscriptions.

The new behavior allows you to add and update entitlements to plans and add-ons, and roll them out to existing subscriptions without affecting their price.

When you're ready to migrate subscriptions to the latest package and price versions, you can do so using the Stigg Console UI or programmatically using the API. The programmatic approach also allows you to schedule this migration.

When the current price of the subscription is different than the latest published package version, during the migration the customer will be charged or credited the prorated amount until the end of the current billing period depending on whether the latest price is more expensive or cheaper than the current subscription price.

We've added an ability to control the visibility of plans in pricing tables that are rendered using Stigg (either using Stigg's pricing table widget or custom widgets).

The new functionality allows you to provision subscriptions to plans that are hidden from your self service flows.

The plan's visibility can be controlled upon creation, or when editing it by clicking on the "Edit" button that appears under the "Plan details" section. 

Once the plan version is published, the change will be auto-magically reflected in all of the pricing tables that are rendered using Stigg.

More details about the new functionality can be found here.

As part of the frontend integration with Stigg customer information is accessed using a Client API key which is publicly accessible to anyone. 

While the Stigg backend limits access to customer information to a minimum, additional security measures can be taken to ensure that the request is indeed from the requesting user.

We've added the ability to sign and verify the identity of requests to access customer information from the frontend. Under the hood, the mechanism leverages the HMAC SHA256 to sign the requests.

We recommend all customers to enable the hardening mechanism in their client-side applications.

More details about this security measure and how to enable it can be found here.

We've made it easier for customers with an existing customer-base to get up-and-running with Stigg by allowing them to import their existing customers and subscriptions into Stigg in bulk using a CLI tool.

The CLI tool manages the entire import process, and as part of it it's also possible to report customers' usage as well as additional metadata about them.

To import customers and subscriptions into Stigg in bulk simply run the CLI tool with a JSON file that represents the data that should be imported.

If ever need to update data that was already imported into Stigg, it's possible to run the import process again - it's idempotent, so all of the changes will be auto-magically merged. 

More details about the bulk import process and available CLI tool can be found here.

We've made it easier for customers to model their pricing in Stigg - during the modeling process customers can now inherit from plans that have still not been published ("draft plans"), and publish their pricing once it has been fully defined in Stigg.

When publishing a plan that inherits from a draft plan, the relevant draft plan must first be published.

More details about plan inheritance can be found here.

We've added an ability to integrate Stigg with an identity provider (IdP) to allow secure access to Stigg using single sign-on (SSO).

When enabled, anyone that's granted access to the Stigg application within the identity provider, either specifically or as part of a security group, will be able to join the Stigg account and require authentication via SSO in order to access it. The authentication itself is performed using the Security Assertion Markup Language (SAML) standard.

In order to determine whether SSO is required to access the account, upon login to Stigg customers are first asked to enter their email address. If the email address belongs to an account that requires SSO, the users will be authenticated using the integrated identity provider. Otherwise, standard authentication (for example: username and password) will take place.

More details about Stigg's support for single sign-on (SSO) and how to set it up can be found here.

At Stigg we believe that you have full ownership of your data, and therefore allow you to export it at all times.

You can also leverage exported data to compare different Stigg environments, for example: compare staging and production.

Exporting data can be done programmatically. To assist you with the process, we create an example repository with editable snippets.

More details about the export process can be found in our technical documentation and in the example repository.

We've made it easier for customers with applications built using Vue.js to embed Stigg's self-service components by leveraging Stigg's Vue.js SDK.

More details about the Vue.js SDK and its integration can be found here.

Stigg supports the creation of multiple environments in each account in order to support customers' existing product development process, for example: Development, Staging, Production, etc.

We've now added the ability to copy the product catalog from an existing environment when creating new environments. This action is useful in the following cases:

The common way to integrate with Stigg is by using Stigg SDKs or API, but it's also possible to leverage Stigg's cloud services and UI to manage your product catalog and subscriptions, while still owning a replica of the data, and building a custom integration on top it. 

We like to call that "Bring Your Own Solution" (or BYOS) type of integration.

If any of the following is true, you might consider the BYOS approach:

1. You already have an entitlement management solution that provisions customers with access to your product, and switching over is too much effort.
2. You prefer not to depend on the availability of Stigg cloud services or SDKs for enforcing access to features.

The BYOS integration method allows you to keep using your existing solution (or build one) by sourcing its data from Stigg.

More details about this approach can be found here.