Changelog

This week, we released several quality-of-life improvements to our Developer Dashboard, with a focus on exports and the Review & License Recovery apps.

Improved UX of the Review & License Recovery App

Following our recent rebranding of the License Recovery and Review app, we’re rolling out a set of UX improvements to make these applications more intuitive and resilient.

The forms are now reactive to validation issues upfront, helping users identify and resolve problems earlier in the flow. We also addressed a few layout inconsistencies to ensure a cleaner and more predictable experience.

Fixes in the Exports

We identified a couple of minor gaps in our export mechanism that could lead to missing context in exported data.

• The licenses export was missing the license key
• The affiliates export was missing the user ID

Both issues have been resolved with today’s deployment, ensuring exports now include all the expected fields.

Fixed License Unit in the Analytics UI

We noticed an issue where the license unit was not correctly reflected in the Analytics filtering UI.

This has now been fixed, and the label correctly reflects your configured license unit.

We are glad to announce that we have started collecting, reporting, and remitting VAT in Norway for all B2C transactions. The VAT handling follows the same model used for other European authorities.

For applicable transactions where VAT is collected, a compliant VAT invoice is automatically generated.

The invoice clearly shows the VAT amounts in both the original transaction currency and the local NOK currency, as required by regulations.

For B2C transactions, companies can enter their Norwegian VAT number and, after validation, will be exempt via the reverse-charge scheme.

The rollout is automatic and applies to all Norwegian transactions from now on.

We are releasing a new feature aimed at easing the life of AI SaaS makers. In the age of AI, consumptive or usage-based pricing has become increasingly popular, and Freemius supports this model out of the box (check our video tutorial).

We also understand that this pricing model can directly impact your refund policy. For example, if you are building a generative AI application with a subscription and top-up model, you may want to offer a money-back guarantee only for unused credits.

You can now configure this behavior directly from the Freemius Developer Dashboard. Simply go to Plans → Refund Policy and enable the “Limit refunds to unused credits for usage-based features” checkbox.

Once enabled, Freemius will automatically include the appropriate clause in the refund policy generated for your product. You can read more about this behavior in our documentation.

Please note that this feature is currently available for SaaS-type products only. If you have other product types and a valid use case, feel free to reach out to our support team and we will be happy to explore enabling this option.

This week we’re rolling out a few improvements to our Documentation website.

New Feature: Filter Documentation by Product Type

At Freemius, we’ve been pushing hard to expand our platform for SaaS makers. This has introduced a growing set of new features, tools, SDKs, and supporting documentation (if you haven’t already, you can take a quick look at our Year in Review to see what’s new).

As the documentation grew, it became increasingly important to clearly separate WordPress- and SaaS-related guides, so makers don’t have to second-guess which SDKs or tools apply to their product.

With that in mind, we’ve introduced a filtering concept on the documentation pages. You can now select SaaS or WordPress to view a focused subset of guides relevant to that product type, or keep All selected to browse everything.

You’ll also notice that some pages adapt based on the selected category. For example, the Sales Analytics documentation now reflects the chosen product type where applicable.

This should make it easier to understand which features and workflows apply to the type of product you’re building. With this foundation in place, we’ll gradually roll out more fine-tuned and targeted guides.

More Guidance for LLM and AI

We recognize the growing importance of building with LLMs (large language models) and AI-powered tooling. To make our documentation easier to consume by AI scrapers, agents, and developer tools, we’re now exposing the following resources in the footer:

• llms-full.txt — All of our documentation bundled into a single, large Markdown file.
• llms.txt — A summarized version of the documentation with links to individual guides, in Markdown format.
• OpenAPI — Direct access to our OpenAPI specification.

One of the many useful features of the Freemius Developer Dashboard is the ability to explore all your users in the context of a Store. Since a store can have multiple products, this view makes it easier to see all users in one place. The same UI also allows you to view and update information for individual users.

It came to our attention that the Billing Information form in this view was not working correctly and was failing to update any of the fields.

With today’s deployment, this issue has been fixed and billing details can now be updated as expected.

We identified an issue in our Customer Portal where the country dropdown was not correctly reflecting the user’s billing country.

This has now been fixed, and the dropdown will consistently show the correct billing country for the user.

We have added a new tab to the Product Settings page called Useful Links. This tab brings together several self-service tools—such as the Customer Portal and the License Recovery Tool—that you can easily share with your customers. In addition, it also lists all legal pages that Freemius generates for your product as your MoR.

You can access this section from Settings → Useful Links.

By grouping these resources in a single place, this update makes it easier to discover and share some of the built-in tools Freemius provides to help with customer support and product management.

We have rolled out a major update to the Developer Dashboard aimed at improving the onboarding experience for makers. Some time ago, we introduced the Setup Checklist to outline the steps makers need to follow to integrate their product with Freemius.

However, we realized that the button was not prominent enough and was easy to miss. To improve this experience and make the next required step more obvious, we have introduced a new banner at the top of the Developer Dashboard.

This banner highlights only the next mandatory step and automatically gets out of the way once the integration is complete. Makers can still access the full Setup Checklist page at any time to review optional steps and further customize or grow their product.

Our Developer Dashboard shows IDs and keys in various places. For example, the Settings → API & Keys section displays the product ID along with its public and secret keys.

Similarly, on the Plans page we show the plan ID.

And within individual plans, we display the pricing ID.

These details are critical, especially for SaaS makers integrating with our official SDK, as keys and IDs are required at different stages of the integration process.

Until now, we used generic labels such as ID or Secret Key across the UI. It came to our attention that this could be confusing, particularly for makers who are new to the Freemius platform.

To improve clarity and make the UI more intuitive, we reviewed the Developer Dashboard and introduced more descriptive labels, such as Plan ID and Product Secret Key as you can see in the screenshots above. This helps makers quickly identify the exact information they need without ambiguity.

The secret key our system generates (for example, for products) can include various special characters, including the $ sign. While this is usually fine for many systems, some frameworks, like Next.js, interpret $ as a reference to another variable and attempt to interpolate it. To avoid this, makers needed to escape the secret key using \$.

For example, if the generated secret key was:

sk_1234$abcd

then, when used with the Next.js framework, it needed to be escaped as:

sk_1234\$abcd

While the workaround is straightforward, this behavior is not always obvious and has led to wasted time debugging why integrations were failing.

To avoid running into this situation, starting today, no newly generated secret keys will include the $ sign. Existing secret keys are not affected in any way.

If needed, you can go to Product → Settings → API & Keys and click the “Regenerate” button to create a fresh key without the $ sign.

After releasing invoices for zero-value payments, we noticed that the Developer Dashboard was also listing the first zero-value payment for trials. Since this information is internal to our system and does not provide any actionable value to makers, we’ve refined the behavior.

Going forward, the Dashboard (and API) will only surface relevant zero-value payments along with their associated invoices, keeping the UI cleaner and more focused.

In addition, we fixed a regression where a payment-like email was mistakenly sent when users updated their payment method.

Freemius supports proration out of the box. Proration means offering a discount on license upgrades based on the remaining days of usage. For example, a customer might have purchased an annual license of planA three months ago and now wants to upgrade to planB. In such cases, our Checkout automatically applies a proration discount for the remaining nine months. This acts as a strong incentive for customers to upgrade to higher plans.

For lifetime licenses, proration discounts were previously limited to a 30-day window. The reasoning behind this default is clearly explained in our documentation. However, we noticed that this recommended limit does not work equally well for all makers—especially for products where lifetime licenses are the primary offering and upgrades may happen much later.

To better support these use cases, we have introduced a new option that allows you to configure the proration period for lifetime licenses.

You can now navigate to Plans → Prorated Discount and update the configuration from there.

The proration period can be set to any custom number of days, including Unlimited. For more details, please refer to the updated documentation.

Our webhook mechanism includes an error detection system that notifies you when a webhook fails multiple times consecutively. We also have a safeguard in place where, if a webhook fails more than 100 times, it is automatically disabled to avoid unnecessary load and potential downtime on your server.

However, it came to our attention that we were not properly clearing the failure counter once the webhook endpoint recovered. This meant that even after the server started responding correctly, the accumulated failures could still lead to an automatic disablement.

This week, we’re rolling out an update to make this logic smarter. The failure counter will now correctly reset itself once the webhook endpoint stops returning errors for a sustained period of time.

This week, we’ve opened up the option to customize the Checkout’s confirmation dialog for “App” products.

Until now, this capability was available only for SaaS products. However, we noticed that many app makers have similar post-purchase requirements—for example, sharing a download link or next steps immediately after a successful purchase.

You can now visit Plans → Customization and start configuring the after-purchase dialog for your app products. For more details on the available options, refer to our documentation.

This week we’re releasing a few improvements to the Setup Checklist and related documentation to make the onboarding experience clearer for WordPress makers.

Onboarding Step for Releasing Plans

We have a concept called Releasing Plans, where the paid plans of a product remain hidden to prevent unintended purchases. For new products, this is automatically enabled as soon as a paid plan is added.

However, for existing products or products that were previously using Freemius only for SDK analytics, this flag remains turned off until the maker explicitly enables it. This distinction was not clearly explained before, which led to some confusion.

With this release, we’ve added Releasing Plans as a visible step in the Setup Checklist, making it part of the onboarding flow.

For most new products that intend to sell from the beginning, this step will be automatically completed as soon as the first paid plan is added. For others, the checklist now clearly highlights the required action: visiting the Plans page and enabling the Release Plans toggle.

In addition, we’ve updated our documentation to better explain this behavior.

Improved Explanation for Releasing Add-ons

There is a similar concept for releasing (or listing) add-ons in the WordPress SDK’s Add-on Marketplace. When an add-on is created, it is listed by default. Makers can choose to unlist it while the add-on is still in development. This can be controlled by going to the Settings page of the product and updating the “Show add-on in the WP Admin Add-Ons marketplace” checkbox.

We noticed cases where add-ons were unlisted during development and then unintentionally left unlisted later, which caused confusion when testing the add-on activation flow.

To make the intent of this setting clearer, we’ve improved the inline hint text to better explain its purpose.

Additionally, we’ve refined our documentation to provide clearer guidance around releasing and listing add-ons.