Products
Solutions
Resources
Product Updates
🔧 Holdouts Now Accepts Public Gate IDs
PATCH /console/v1/holdouts/{id} now resolves public gate IDs for targetingGateID, the same way gateIDs and experimentIDs already do.
What you can do now
Set
targetingGateIDto a public gate ID — the slug CAPI returns asidon all write paths — without hitting a 500.Internal IDs still work, so existing GET-edit-PUT round-trips are unchanged.
An unknown gate now returns a clean 400 instead of a 500
nullstill keeps the existing gate,""still clears it.
Why this matters
Now, targetingGateID behaves consistently with the rest of the PATCH endpoint.
Try it out
Review the full API reference in the Statsig Holdouts Console API docs.
☁️ Athena Now Supports Gate and Experiment Keys with . and -
Athena users can now use dots and hyphens in gate and experiment keys without any workarounds.
What you can do now
Use
.and-in gate and experiment keys on Athena, the same way BigQuery and Databricks Warehouse Native users already can.Existing keys without
.or-are untouched. No renaming or migration needed.
Why this matters
Teams running Athena had to avoid dots and hyphens in gate and experiment keys entirely. Now, you can use any naming convention on Athena without workarounds or renaming.
Try it out
No action needed. Start using . and - in your gate and experiment keys on Athena today.
Learn more in the Statsig Warehouse Native docs.
📊 Topline Impact in Warehouse Native
Composite metrics now show the full Topline Impact panel in Warehouse Native experiment results.
What you can do now
See absolute and projected launch impact for composite metrics, the same way you can for ratio, funnel, and retention metrics.
Each component's daily value is computed and combined with its operator before rolling up, so the impact calculation reflects the full composite definition.
Why this matters
Topline Impact tells you the real daily effect your experiment is having on a metric across your entire user base. Now, composite metrics are fully supported, so you can make shipping decisions with the same confidence you have on any other metric type.
Try it out
Open any Warehouse Native experiment result and select a composite metric to see Topline Impact. Learn more in the Statsig Topline Impact docs.
🔐 Granular Delete Permission for Configs
You can now separate the ability to delete configs from the ability to edit them.
What you can do now
Manage Edit, Archive, and Delete as distinct permissions on your Role Permissions page
Why this matters
Previously, delete was bundled into a single "Edit Delete Configs" permission with no way to separate them. Now, you can grant edit access broadly and keep delete access narrow, without having to create workarounds or roles with too many extra permissions.
FYI!
This is opt-in and not on by default. To enable granular delete permissions for your organization, contact your Statsig account team. Once enabled, the separate Delete permission will appear on your Role Permissions page under Project Settings.
Try it out
Learn more in the Statsig Access Management docs.
🔬 Experiment Reviews via Console API and MCP
The full experiment review lifecycle is now accessible over the Console API and the Statsig MCP.
What you can do now
We now have eight new CAPI endpoints and nine new MCP tools cover the complete review lifecycle:
Create a review proposing a change to an experiment
List an experiment's reviews, newest first
Get a single review including status, proposed change, author, and reviewers
Look up who is eligible to approve or reject
Edit a pending review's metadata
Approve or reject an in-flight review
Cancel a pending review
Commit an approved review to apply it to the live experiment
Why this matters
Before, creating and moving an experiment review through approval required the console, blocking any automated workflow that touched a review-gated experiment. Now you can propose, approve, and commit experiment changes entirely through the API or MCP, with no manual console step in the way.
Try it out
If you have the Statsig MCP set up, try a prompt like:
"Open a review to make a decision on
experiment_name, shipping the Test group."
Review the full API reference in the Statsig Console API docs.
🔎 Audit Overrides Across Your Entire Project
You can now query all overrides across your project in a single API call.
What you can do now
We now have one new endpoint available on statsigapi.net/console/v1/:
GET /console/v1/overrides
Why this matters
Before , finding where a user was overridden meant querying each gate, experiment, and layer one by one. Now you can audit overrides project-wide in a single call, whether you're debugging unexpected behavior for a specific user, running a compliance audit, or cleaning up override sprawl.
Try it out
Review the full API reference in the Statsig Overrides Audit docs.
📣 Follow Dynamic Configs
You can now follow and unfollow Dynamic Configs to get notified when they're updated.
What you can do now
Follow a Dynamic Config to receive notifications whenever it's updated
Unfollow at any time to stop receiving notifications
Why this matters
Dynamic Configs often control things like API settings and rollout thresholds. Being able to follow means the right people get notified the moment a Dynamic Config updated, without having to watch the console or find out after the fact.
Try it out
Open a Dynamic Config in the Statsig console and click Follow to subscribe to updates.
Learn more in the Statsig Console docs.
🔍 Feature Gate Reviews in the Console API
The full feature gate review lifecycle is now exposed over the Console API.
What you can do now
Eight new endpoints cover the complete review lifecycle:
POST /gates/:id/reviews create a review with the proposed change
GET /gates/:id/reviews list reviews, newest first
GET /gates/:id/reviews/:reviewID get a single review
PUT /gates/:id/reviews/:reviewID edit metadata or content
PUT /gates/:id/reviews/:reviewID/approve approve
PUT /gates/:id/reviews/:reviewID/reject reject
DELETE /gates/:id/reviews/:reviewID cancel an in-flight review
GET /gates/:id/eligible_reviewers look up eligible reviewers
Why this matters
Before , creating and moving a review through approval required the console, blocking any automated workflow that touched a review-gated gate. Now you can propose, approve, and commit gate changes entirely through the API, with no manual console step in the way.
Try it out
Review the full API reference in the Statsig Console API docs.
🗄️ Parameter Store Management in the Statsig MCP
You can now create and manage Parameter Stores directly through the Statsig MCP.
What you can do now
Three new tools are available on api.statsig.com/v1/mcp:
Create_Param_StoreUpdate_Param_StoreDelete_Param_Store
Why this matters
Now, you can create a store, define its parameters, and point them at a gate or experiment without leaving your agent flow, making end-to-end feature provisioning possible for the first time.
Try it out
If you have the Statsig MCP set up, try a prompt like:
"Using the Statsig MCP, create a Parameter Store called checkout-config and add a static boolean parameter "express_checkout_enabled" set to true.
Learn more in the docs: Statsig MCP Overview.
🧪 Leaner Experiment Reads
Experiment reads just got a lot leaner and easier.
What you can do now
Trimmed and batched experiment reads
Fetch multiple experiments in a single call instead of one round-trip per experiment.
A single experiment trims from ~66 fields down to just what you ask for, achieving up to 95-99% context reduction.
Why this matters
For agentic workflows reasoning across many experiments, pulling full payloads burns through context windows fast. Field trimming and batching keep those workflows lean.
Learn more in the docs: Statsig MCP Overview.
Loved by customers at every stage of growth
