You can now remove an individual user from a Feature Gate override without touching the rest of the list.
One new endpoint is available on statsigapi.net/console/v1/:
DELETE /console/v1/gates/{gateName}/overrides/userID/{userID}
Before this, removing a single user override meant fetching the full override list, mutating it locally, and re-posting it, which could be risky when test runs are happening concurrently. Now, you can target and remove exactly one user, leaving every other override untouched.
Review the full API reference in the Statsig Console API docs.
Statsig Topline Alerts can now page PagerDuty directly.
Add PagerDuty services to the Integrations catalog once with a name and Events API v2 routing key.
Select one or more PagerDuty services per alert in the Notifications settings.
Test your wiring end-to-end before you rely on it โ test pages are tagged [TEST] and never collide with real incidents.
Deleting a PagerDuty service that an alert still references is blocked, and disabled integrations are clearly flagged.
Topline Alerts catch anomalies in your most critical product metrics, but a notification that in Slack or email isn't always enough when something is on fire. Now, the same alert that fires in Statsig can page your on-call team in PagerDuty, closing the gap between detecting a problem and fixing it quickly.
Go to Integrations in the Statsig console, add your PagerDuty service, then open any Topline Alert and configure PagerDuty under Notifications.
Learn more in the Statsig Topline Alerts docs.
You can now submit Autotune changes for review and manage the full review lifecycle across the console, Console API, and MCP.
Submit Autotune configuration changes for review before they reach production.
Approve, reject, or cancel in-flight Autotune reviews from the console, via CAPI, or through the MCP.
Teams with reviews required can now enforce that same approval workflow on Autotunes, the same way they do for gates and experiments.
Teams running Autotune for high-stakes decisions need the same guardrails they have everywhere else. Any change to a live Autotune can shift traffic allocation immediately, so being able to require an approval before it goes out matters. Reviews are now consistent across gates, experiments, and Autotunes.
If you have the Statsig MCP set up, try a prompt like:
"Using the Statsig MCP, open a review to update the winner threshold on
autotune_nameand submit it for approval."
Learn more in the Statsig Reviews docs.
You can now separate the ability to delete configs from the ability to edit them.
Manage Edit, Archive, and Delete as distinct permissions on your Role Permissions page
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.
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.
Learn more in the Statsig Access Management docs.
The full experiment review lifecycle is now accessible over the Console API and the Statsig MCP.
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
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.
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.
You can now query all overrides across your project in a single API call.
We now have one new endpoint available on statsigapi.net/console/v1/:
GET /console/v1/overrides
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.
Review the full API reference in the Statsig Overrides Audit docs.
You can now follow and unfollow Dynamic Configs to get notified when they're updated.
Follow a Dynamic Config to receive notifications whenever it's updated
Unfollow at any time to stop receiving notifications
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.
Open a Dynamic Config in the Statsig console and click Follow to subscribe to updates.
Learn more in the Statsig Console docs.
The full feature gate review lifecycle is now exposed over the Console API.
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
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.
Review the full API reference in the Statsig Console API docs.
You can now create and manage Parameter Stores directly through the Statsig MCP.
Three new tools are available on api.statsig.com/v1/mcp:
Create_Param_Store
Update_Param_Store
Delete_Param_Store
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.
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.
Experiment reads just got a lot leaner and easier.
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.
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.