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

We're excited to announce Agent Skills for Claude Code - a powerful plugin that gives AI coding agents the domain knowledge they need to safely integrate Stigg into your app.

While our MCP server gives agents the tools to take action, Agent Skills give them the brains to use those tools correctly, embedding monetization best practices and strict safety guardrails directly into Claude's context window. 

⭐️ Why it matters

AI agents write great code, but they lack the structural context required for complex operations. Stigg Agent Skills solve this by providing:

• Pricing Best Practices: Teaches Claude how to structure complex pricing models, entitlement-gating, and checkout sequences cleanly.
• Subscription Sequencing: Guides Claude on handling upgrades, downgrades, and cancellations.
• Safety Guardrails: Trains the agent to avoid common monetization mistakes and protect production environments.

⚒️  Get started

Install the plugin in Claude Code or Claude Desktop today, or check out the Stigg Agent Skills Documentation for full details. 

🍿 See it in action

We're excited to announce that the Stigg CLI is now available in Public Beta.

🆕 What’s new

You can now interact with the Stigg REST API directly from your terminal using our new Command Line Interface (CLI). The Stigg CLI acts as a lightweight wrapper, allowing developers to query environments, list customers, retrieve subscriptions, and check entitlements without having to write raw HTTP requests or custom scripts.

⭐️ Why it matters

Developers need the right tools for different workflows. While our recently launched MCP Server allows you to manage Stigg using natural language, the Stigg CLI is built for speed, precision, and automation.

Understanding when to use which tool can significantly speed up your development process:

• When to use the Stigg CLI: The CLI is perfect for deterministic, programmatic workflows. It is the go-to tool for scripting automated administrative tasks, integrating Stigg commands into your CI/CD pipelines, or executing quick, repeatable queries directly from your terminal (e.g., verifying a specific customer's entitlement or listing all active plans). It requires no AI context and gives you explicit control over your environment.
• When to use the MCP Server: The MCP Server is designed for AI-driven development. It is best used within AI assistants like Cursor or Claude Desktop when you want to explore the API, scaffold code, or handle complex testing scenarios using natural language prompts without leaving your IDE.

Together, they provide comprehensive developer coverage, ensuring you can integrate and manage your pricing infrastructure securely and efficiently.

⚒️ Get started

Getting started with the CLI is as easy as 1-2-3:

1. Install the CLI via Homebrew or Go.
2. Authenticate using your environment specific API-key.
3. Use - query and manage your Stigg environments via CLI commands

For more details, check out the Stigg CLI documentation. 

We're excited to announce that the Stigg MCP Server is now available in Public Beta.

🆕 What’s new

You can now expose your Stigg environment directly to any AI agent or coding assistant that supports the Model Context Protocol (MCP) - including Claude Desktop, Cursor, ChatGPT, Windsurf, and more. Once connected, your AI assistant can interact with the entire Stigg API surface using natural language.

⭐️ Why it matters

Building and testing pricing models often requires switching between code, API documentation, and the Stigg UI. With the Stigg MCP Server, you can streamline your development and testing workflows directly from your IDE or AI chat interface without writing a single API call manually.

Your AI agent can now securely act on your behalf to:

• Manage your catalog: Create, update, and list plans, add-ons, and features.
• Handle customers & subscriptions: Provision customers, preview or create subscriptions, and grant promotional entitlements.
• Test usage & entitlements: Check if a customer has access to a specific feature, report metered usage, or submit raw metering events for testing.

⚒️ Get started

The Stigg MCP Server connects to your AI client using a standard HTTP transport or via our NPM package, authenticated securely via your Stigg environment API keys.

To connect your favorite AI assistant:

1. Generate an API key in the Stigg app under Integrations > API keys (we highly recommend creating a dedicated, scoped key for your AI client).
2. Configure your specific AI client (like Cursor, Claude, or ChatGPT) to point to the Stigg MCP Server.
3. Start asking your agent to interact with Stigg! (e.g., "Check if customer X has access to the premium feature" or "Create a new test customer and subscribe them to the Pro plan").

For step-by-step configuration snippets for all major AI clients, check out the Stigg MCP Server documentation.