You can now consume credits directly in Stigg without requiring an active subscription. This allows you to use Stigg as a standalone credits engine for tracking balances, enforcing entitlements, and governing usage, while managing subscriptions entirely in your own platform.

✨ What's New

Previously, consuming credits through reportUsage or reportEvent required customers to have an active subscription with credit-based entitlements. With this release, credits can now be consumed directly against customer credit grants, completely bypassing the subscription layer.

This enables two common use cases:

• Standalone credits engine: Use Stigg as a dedicated credits engine while managing subscriptions in your own billing system.
• Hybrid integration: Integrate an existing credit model with Stigg to track balances, consume credits, and enforce entitlements.

The release includes:

• Direct UI & API consumption: Grant promotional or paid credits using the existing grantCredit functionality and consume directly against those grants.
• Full ledger visibility: Complete visibility in the credit ledger for every credit grant and consumption event.
• New SDK capabilities: Call getCreditEntitlement, consumeCredits, and consumeCreditsAsync for customers without any active subscription.

⭐️ Why It Matters

Not every product needs subscription management. Many teams already have an existing billing platform or custom subscription system and simply need a reliable way to manage credits and enforce usage.

Direct credit consumption enables you to:

• Decouple credits from subscriptions: Build usage-based products without coupling credits to subscription lifecycles.
• Keep your billing platform: Retain your existing subscription or billing platform while offloading the consumption logic.
• Audit every single action: Track every credit grant and consumption event reliably in the Stigg ledger.

📦 Availability

Direct credit consumption is available in the Stigg app and across our developer ecosystem, including GraphQL, REST, and our associated SDKs:

REST-based SDKs

• TypeScript: v0.1.0-beta.36
• Python: v0.1.0-beta.31
• Go: v0.1.0-beta.33
• Java: v0.1.0-beta.31
• Ruby: v0.1.0-beta.35

GraphQL-based SDKs

• Node.js: v4.48.0
• Python / Go / .NET: v6.16.0
• Java: v6.17.0
• Ruby: v6.14.0

You can now configure credit entitlements with soft limits, allowing customers to continue accessing your product even after their credit balance reaches zero.

🆕 What's New

Until now, credit entitlements enforced a hard limit once a customer's credit balance was depleted.

With this release, you can now choose whether a credit entitlement is enforced as a hard limit or a soft limit directly from the plan and add-on editor.

When a credit entitlement is configured as a soft limit:

• Customers can continue consuming credits after their balance is exhausted
• Access checks continue to return access granted
• Stigg surfaces a soft-limit indication so your application can distinguish between available credits and overage usage

This gives you greater flexibility in how you manage credit-based plans and overage experiences.

⭐️ Why It Matters

Not every usage-based business wants to block customers the moment they run out of credits.

Soft limits enable you to:

• Allow overages while maintaining visibility into credit consumption
• Prevent service interruptions for high-value customers
• Create usage-based plans that balance flexibility with control
• Build grace-period and overage billing experiences

Whether you're monetizing API calls, AI requests, or platform usage, soft limits let you decide when credit balances should enforce access and when they should simply act as a billing signal.

📦 Availability

Soft limits for credit entitlements are available in the Stigg app and across our developer ecosystem, including GraphQL, REST, and our associated SDKs:

REST-based SDKs

• Python: v0.1.0-beta.27
• Go: v0.1.0-beta.28
• Java: v0.1.0-beta.26
• Ruby: v0.1.0-beta.30

GraphQL-based SDKs

• Node.js: v4.45.0
• Python / Go / .NET: v6.13.0
• Java: v6.14.0
• Ruby: v6.11.0

We've enhanced credit ingestion to support real-time balance updates. Applications can now deduct credits synchronously and receive an updated balance immediately in the response, enabling real-time usage experiences without waiting for ingestion to complete.

🆕 What's New

Previously, credits were consumed through reportEvent, which processes usage asynchronously. As a result, credit balances were only updated after ingestion, introducing a delay of several seconds before the latest balance was available.

With this release, reportUsage now supports synchronous credit deductions.

When usage is reported:

• Credits are deducted immediately
• The updated balance is returned in the reportUsage response
• Applications can display current credit balances without waiting for ingestion pipelines to complete

⭐️ Why It Matters

Many usage-based products rely on real-time credit visibility and enforcement.

With synchronous deductions, you can:

• Show customers accurate credit balances immediately after usage occurs
• Enforce credit limits in real time
• Build AI, API, and consumption-based products without balance update delays
• Deliver a more responsive usage experience

Whether you're charging credits per API call, AI request, or other metered action, customers can now see the impact of their usage instantly.

⚒️ Getting Started

Use reportUsage to report and consume credits synchronously.

The updated balance is returned directly in the API response and is supported by the latest Stigg SDKs.

📦 Availability

To consume credits synchronously and receive updated balances in the reportUsage response, upgrade to one of the following SDK versions:

REST-based SDKs

• Python: v0.1.0-beta.29
• Go: v0.1.0-beta.30
• Java: v0.1.0-beta.28
• Ruby: v0.1.0-beta.32

GraphQL-based SDKs

• Node.js: v4.46.0
• Python / Go / .NET: v6.14.0
• Java: v6.15.0
• Ruby: v6.12.0

We're excited to introduce significant updates to our credit tracking UX, making it easier than ever for you and your customers to understand exactly how credits are allocated and consumed.

With a redesigned usage overview and a new searchable group-by filter for usage history, you now have complete clarity and effortless control over your credit data.

🆕 What’s new?

• Granular Credit Overviews: The usage overview section has been overhauled to provide deep visibility into your credit pools. You can now see an explicit breakdown of granted credits between recurring and one-time credit grants. We’ve also enhanced the UI to provide immediate clarity on the exact number of credits used, credits remaining, and the timeline for the next reset period.
  
  
  

• Searchable Group-by Dimensions: Analyzing usage history is now much faster. The "Group by" filter in the usage history view now features a built-in search bar. Instead of scrolling through an endless list of properties when your reported usage events include a massive amount of metadata, you can simply type to find the exact dimension you want to use to break down your data.

  
  

We're excited to introduce a major update to credit tracking: Credit usage breakdown by dimensions of reported usage events. 

You can now slice-and-dice credit consumption history using the custom dimensions attached to your usage events - such as user ID, workspace ID, LLM model type, and more - giving you and your customers unprecedented visibility into how credits are spent.

🆕 What’s new?

Previously, Stigg only allowed you to view credit usage history at the feature level (i.e., which feature drew down from the credit pool).

With this update, you can drill down into the granular event attributes behind those feature drawdowns. Furthermore, you can break down consumption by multiple dimensions simultaneously - for instance, grouping usage by both Feature ID and User ID to see exactly which team member consumed the most credits on a specific feature.

To ensure performance remains lightning-fast even with high volumes of granular data, all breakdown results are fully paginated.

⭐️ Why it matters

• End-Customer Transparency: Build trust by showing your customers exactly who or what is driving up their bill (e.g., "User A spent 400 credits on gpt-4o queries").
• Internal Troubleshooting & BI: Equips your customer success and engineering teams with the granular data needed to debug unexpected usage spikes or run deep business intelligence analyses on credit utilization.

🍿 See it in action

Via the Stigg API & SDKs - You can request dimension-based breakdowns programmatically. Simply pass the groupBy array in your credit usage history queries.

In the Stigg App - when viewing a customer's credit pool in the Stigg dashboard, you can now toggle custom dimension filters to instantly generate usage charts and breakdown tables based on your custom event metadata:

📦 Availability

Credit usage breakdown by event dimensions is available immediately for all customers. You can access it directly within the Stigg app UI or query it programmatically via the latest versions of the Stigg API and SDKs:

REST-based SDKs

• TypeScript: v0.1.0-beta.15
• Python: v0.1.0-beta.13
• Go: v0.1.0-beta.15
• Java: v0.1.0-beta.13
• Ruby: v0.1.0-beta.15

GraphQL-based SDKs

• Node.js: v4.43.0
• Python: v6.11.0
• Go: v6.11.0
• Java: v6.11.0
• .NET: v6.11.0
• Ruby: v6.9.0

We're introducing additional granularity for managing termed subscriptions in Zuora, giving you the flexibility to define completely different term periods for an initial subscription term and its subsequent renewals.

🆕 What’s new?

Previously, setting a the subscription term period applied uniformly to both the initial and renewal terms. With this release, you can separate these timeframes entirely by including the following keys in the subscription metadata:

1. ZUORA__InitialPeriodType - accepts the following values: DAY, WEEK, MONTH, YEAR (default: MONTH).

2. ZUORA__RenewalPeriodType - accepts the same values.

The ZUORA__periodType that was previously used to manage the subscription term in Zuora has been marked for deprecation and passing any of the above keys will override its value.

Stigg continues to fully support syncing subscriptions to Zuora as termed subscription upon provisioning, as well as updating existing subscriptions from evergreen to termed and vice versa.

⭐️ Why it matters

Enterprise and sales-led contracts rarely follow a uniform timeline. A standard B2B negotiation strategy can involve locking a customer into an initial commitment to secure an enterprise discount, while setting the contract to roll over to a different renewal structure afterward.

This update allows your provisioning logic to reflect those exact contract terms dynamically at the moment of sale, eliminating the manual overhead of adjusting renewal terms directly inside Zuora after a subscription is created.

📦 Availability

These granular metadata configurations are available immediately for all customers using our native Zuora billing integration. To learn more about structuring your contract parameters, check out the updated Zuora Termed Subscriptions Documentation.

Testing and managing your billing stack just got a lot smoother. We're excited to announce native support for the Zuora Payment Form directly inside the Stigg app.

This update simplifies the integration flow with Zuora and requires less parameters during setup.

🆕 What’s new?

• Unified Payment Capture Experience: You can now enter and test payment methods inside the Stigg app using Zuora’s standard Payment Form component. This mirrors your production environment's checkout behavior.
• New Sleek Side Panel UX: To keep your workflows uninterrupted, we’ve moved the payment details capture interface into a convenient side panel that slides out on demand.
• Direct-to-Zuora Storage: Security remains a top priority. All sensitive payment details entered through this form are sent and stored directly within Zuora - Stigg never touches or stores this data.
• Legacy Payment Page Support: If your application still leverages the older Zuora Payment Page component instead of the newer form, our team has you covered. Simply contact Stigg support, and we can configure your Stigg app environment to use your existing payment page setup.

⭐️ Why it matters

• Simplified Integration: Integration Zuora and Stigg requires much less parameters than before.
  
• Improved User Experience: The Zuora Payment Page offers a more streamlined and modern experience that appears more natively integrated with the Stigg app.

📦 Availability

This feature is available immediately for all Stigg vendors utilizing the Zuora integration. Check out the Zuora Payment Form Documentation for more details on customizing the underlying form components.

🍿️ See it in action

Managing usage and spending boundaries across multi-tenant or multi-user applications just got a whole lot more granular. We are excited to announce Resource-Level Credit Pools, allowing you to isolate credit balances, ledgers, and auto-recharge configurations for individual customer resources.

Previously, credit balances were managed at the global customer level. With this update, you can now provision distinct credit wallets for specific resources - such as individual workspaces, or even specific team members under a single customer account.

🆕 What’s new?

When a subscription is assigned to a specific customer resource, Stigg now automatically spins up an isolated, resource-specific credit pool.

Each resource-level credit pool operates as an independent wallet featuring its own:

• Dedicated Credit Grants: Award or sell credits that are strictly locked to a single resource.
• Isolated Credit Ledger & Usage History: Track exactly how, when, and where a specific resource is consuming its credit balance.
• Independent Auto-Recharge Configurations: Set up tailored auto-recharge rules that trigger top-ups only when a specific resource's balance runs low.

The Stigg app has also been updated to give you full visibility into your multi-resource architecture:

• Credits Tab: You can now filter your global credit views using the new Resource ID drop-down menu to view isolated ledgers.
• Subscription View: When viewing any resource-specific subscription, the UI will display the dedicated credit pool history and auto-recharge statuses directly inline.

⭐️ Why it matters

Modern SaaS products frequently require usage enforcement to happen below the billing account level. This is particularly critical for B2B applications offering team plans or usage-heavy developer platforms.

• Implement Per-User Credit Pools: You can now cleanly build a team topology where a corporate customer pays a single invoice, but each individual team member receives a dedicated, non-shareable credit pool for their personal usage enforcement.
• Prevent Resource Starvation: Ensure that a single noisy workspace or rogue API token cannot drain the entire credit balance of a parent customer account.

⚒️ Get started

Resource-level credit pools require no manual initialization - they're automatically generated whenever you provision a subscription and assign it to a specific resource by passing the resource ID.

Credits can be granted to a resource-specific credit pool by passing the resource ID. Similarly, credits can be consumed from a resource-specific credit pool by passing the resource ID when reporting usage events to Stigg.

🍿️ See it in action

We've added more granular date filters for retrieving credit usage data.

🆕 What's new?

You can now pass specific start and end dates when retrieving credit usage data. Before this change it was only possible to pass an enum value for the desired period (e.g. last week, month, year, etc.).

⭐️ Why it matters

This update empowers you to build granular, time-based customer usage charts, providing your users with deeper insights into how they consume their credits. By isolating usage data within specific windows, you can better visualize trends, identify peak usage periods, and help customers manage their balances more effectively.

⚒️ Get started

To start building your own usage charts, head over to our API reference to see the full schema. If you use our SDKs, simply pass the startDate and endDate parameters when retrieving credit usage.

📦 Availability

The new date filters are available in the Stigg app and across our entire developer ecosystem, including GraphQL, REST, and our associated SDKs:

REST-based SDKs

• TypeScript: v0.1.0-alpha.31
• Python: v0.1.0-alpha.31
• Go: v0.1.0-alpha.29
• Java: v0.1.0-alpha.52
• Ruby: v0.1.0-alpha.29

GraphQL-based SDKs

• Node.js: v4.40.0
• Python / Java / Go / .NET: v6.10.0
• Ruby: v6.8.0

🍿 See it in action

We've added support for a value of 0 in charges and variable entitlements when provisioning and updating subscriptions. This update provides additional flexibility when managing sales-led deals and enterprise contracts via the Stigg app, API and SDKs.

🆕 What’s new?

Previously, passing a zero value for explicit subscription overrides could cause validation constraints or conflict with underlying plan defaults. With this release:

• Zero-Quantity Charges: You can now explicitly pass a quantity of 0 for line item charges.
• Zero-Value Entitlements: You can now set a value of  0  to variable entitlement.

Setting such values will disable the affected metered features.

⭐️ Why it matters

Enterprise and sales-led subscription workflows are inherently dynamic. Sales teams often negotiate custom packages that deviate from your standard pricing models.

This enhancement gives you the flexibility to:

• Enforce strict feature gating: Fully shut down access to specific variable features by overriding them to 0, rather than relying on default tiers.
• Model complex contract adjustments: Handle unique trial extensions, specific feature carve-outs, or temporary contract modifications cleanly within Stigg's provisioning logic without needing to create a separate custom plan for every single customer edge case.

⚒️ Get started

This capability is available out of the box when using Stigg's standard subscription management functions. 

🍿 See it in action