Migrating from the Legacy Python SDK? See our Migration Guide.
Setup the SDK
1
Install the SDK
Installation
Tested Platforms
Specific Platform Info
Specific Platform Info
Docker base images where the Python Core SDK has been tested and verified:
Docker Base Image | Description |
---|---|
python:3.7-alpine | Python 3.7 on Alpine Linux |
python:3.7-buster | Python 3.7 on Debian Buster |
python:3.7-slim | Python 3.7 slim variant |
quay.io/pypa/manylinux2014_x86_64 | Manylinux 2014 x86_64 for broad Linux compatibility |
python:3.10-alpine | Python 3.10 on Alpine Linux |
python:3.10-slim | Python 3.10 slim variant |
2
Initialize the SDK
After installation, you will need to initialize the SDK using a Server Secret Key from the Statsig console.There is also an optional parameter named
Server Secret Keys should always be kept private. If you expose one, you can disable and recreate it in the Statsig console.
options
that allows you to pass in a StatsigOptions to customize the SDK.initialize
will perform a network request. After initialize
completes, virtually all SDK operations will be synchronous (See Evaluating Feature Gates in the Statsig SDK). The SDK will fetch updates from Statsig in the background, independently of your API calls.⚠️ Warning: Process Forking and WSGI Servers
Important: Never fork processes after callingstatsig.initialize()
. Doing so will put Statsig in an undefined state and may cause deadlock.The Python Core SDK uses internal threading and async runtime components that do not work correctly when copied across process boundaries. When a process forks after initialization, these components can become corrupted, leading to:- Deadlocks in event logging
- Hanging initialization calls
- Unpredictable SDK behavior
- Silent failures in feature evaluation
Initializing with WSGI servers
For production deployments using WSGI servers like uWSGI or Gunicorn, ensure Statsig is initialized after the worker processes are forked, not in the main process.- uWSGI
- Gunicorn
- FastAPI
initialize
will perform a network request. After initialize
completes, virtually all SDK operations will be synchronous (See Evaluating Feature Gates in the Statsig SDK). The SDK will fetch updates from Statsig in the background, independently of your API calls.Working with the SDK
Checking a Feature Flag/Gate
Now that your SDK is initialized, let’s fetch a Feature Gate. Feature Gates can be used to create logic branches in code that can be rolled out to different users from the Statsig Console. Gates are always CLOSED or OFF (thinkreturn false;
) by default.
From this point on, all APIs will require you to specify the user (see Statsig user) associated with the request. For example, check a gate for a certain user like this:
Reading a Dynamic Config
Feature Gates can be very useful for simple on/off switches, with optional but advanced user targeting. However, if you want to be send a different set of values (strings, numbers, and etc.) to your clients based on specific user attributes, e.g. country, Dynamic Configs can help you with that. The API is very similar to Feature Gates, but you get an entire json object you can configure on the server and you can fetch typed parameters from it. For example:get_dynamic_config()
method returns a DynamicConfig object that allows you to:
- Fetch typed values with fallback defaults using
get_string()
,get_float()
,get_boolean()
, andget_integer()
- Access evaluation metadata through properties like
rule_id
andid_type
- Configure evaluation behavior using
DynamicConfigEvaluationOptions
Getting a Layer/Experiment
Then we have Layers/Experiments, which you can use to run A/B/n experiments. We offer two APIs, but often recommend the use of layers, which make parameters reusable and let you run mutually exclusive experiments.Retrieving Feature Gate Metadata
In certain scenarios, you may need more information about a gate evaluation than just a boolean value. For additional metadata about the evaluation, use the Get Feature Gate API, which returns a FeatureGate object:Parameter Stores
Sometimes you don’t know whether you want a value to be a Feature Gate, Experiment, or Dynamic Config yet. If you want on-the-fly control of that outside of your deployment cycle, you can use Parameter Stores to define a parameter that can be changed into at any point in the Statsig console. Parameter Stores are optional, but parameterizing your application can prove very useful for future flexibility and can even allow non-technical Statsig users to turn parameters into experiments.Retrieving Parameter Values
Parameter Store provides methods for retrieving values of different types with fallback defaults.Evaluation Options
You can disable exposure logging when retrieving a parameter store:Logging an Event
Now that you have a Feature Gate or an Experiment set up, you may want to track some custom events and see how your new features or different experiment groups affect these events. This is super easy with Statsig—simply call the Log Event API and specify the user and event name to log; you additionally provide some value and/or an object of metadata to be logged together with the event:Sending Events to Log Explorer
You can forward logs to Logs Explorer for convenient analysis using the Forward Log Line Event API. This lets you include custom metadata and event values with each log.Using Shared Instance
In some applications, you may want to create a single Statsig instance that can be accessed globally throughout your codebase. The shared instance functionality provides a singleton pattern for this purpose:Statsig.new_shared(sdk_key, options)
: Creates a new shared instance of Statsig that can be accessed globallyStatsig.shared()
: Returns the shared instanceStatsig.has_shared_instance()
: Checks if a shared instance exists (useful when you aren’t sure if the shared instance is ready yet)Statsig.remove_shared()
: Removes the shared instance (useful when you want to switch to a new shared instance)
has_shared_instance()
and remove_shared()
are helpful in specific scenarios but aren’t required in most use cases where the shared instance is set up near the top of your application.Also note that only one shared instance can exist at a time. Attempting to create a second shared instance will result in an error.Manual Exposures
By default, the SDK will automatically log an exposure event when you check a gate, get a config, get an experiment, or get a layer. However, there are times when you may want to log an exposure event manually. For example, if you’re using a gate to control access to a feature, but you don’t want to log an exposure until the user actually uses the feature, you can use manual exposures. All of the main SDK functions (check_gate
, get_dynamic_config
, get_experiment
, get_layer
) accept an optional disable_exposure_logging
parameter. When this is set to True
, the SDK will not automatically log an exposure event. You can then manually log the exposure at a later time using the corresponding manual exposure logging method:
- Feature Gates
- Dynamic Configs
- Experiments
- Layers
Statsig User
TheStatsigUser
object represents a user in Statsig. You must provide a userID
or at least one of the customIDs
to identify the user.
When calling APIs that require a user, you should pass as much information as possible in order to take advantage of advanced gate and config conditions (like country or OS/browser level checks), and correctly measure impact of your experiments on your metrics/events. At least one ID (userID or customID) is required because it’s needed to provide a consistent experience for a given user (click here)
Besides userID, we also have email, ip, userAgent, country, locale and appVersion as top-level fields on StatsigUser. In addition, you can pass any key-value pairs in an object/dictionary to the custom field and be able to create targeting based on them.
Private Attributes
Private attributes are user attributes that are used for evaluation but are not forwarded to any integrations. They are useful for PII or sensitive data that you don’t want to send to third-party services.Statsig Options
You can pass in an optional parameteroptions
in addition to sdkKey
during initialization to customize the Statsig client. Here are the available options that you can configure.
StatsigOptions
StatsigOptions
Custom URL for fetching feature specifications.
How often the SDK updates specifications from Statsig servers (in milliseconds).
Sets the maximum timeout for initialization requests (in milliseconds).
Custom URL for logging events.
When
true
, disables all event logging.When
true
, disables all network functions: event & exposure logging, spec downloads, and ID List downloads. Formerly called “localMode”.How often events are flushed to Statsig servers (in milliseconds).
Maximum number of events to queue before forcing a flush.
Enable/disable ID list functionality. Required to be
true
when using segments with more than 1000 IDs. See ID List segments for more details.If set to true, the SDK will NOT attempt to parse UserAgents (attached to the user object) into browserName, browserVersion, systemName, systemVersion, and appVersion at evaluation time, when needed for evaluation.
When set to true, the SDK will wait until user agent parsing data is fully loaded during initialization. This may slow down by ~1 second startup but ensures that parsing of the user’s userAgent string into fields like browserName, browserVersion, systemName, systemVersion, and appVersion is ready before any evaluations.
If set to true, the SDK will NOT attempt to parse IP addresses (attached to the user object at user.ip) into Country codes at evaluation time, when needed for evaluation.
When set to true, the SDK will wait for country lookup data (e.g., GeoIP or YAML files) to fully load during initialization. This may slow down by ~1 second startup but ensures that IP-to-country parsing is ready at evaluation time.
Custom URL for fetching ID lists.
How often the SDK updates ID lists from Statsig servers (in milliseconds).
Whether to fallback to the Statsig API if custom endpoints fail.
Environment parameter for evaluation.
Controls the verbosity of SDK logs.
Adapter / Interface to use persistent assignment within SDK. More details
Adapter to listen monitor the health of SDK. See details
Custom data store implementation for storing and retrieving configuration data. Used for advanced caching or storage strategies.
Maximum number of batches of events to hold in buffer to retry.
Custom fields to include in all events logged by the SDK.
Compression method for exposure logging. Options: “gzip”, “dictionary”
Configuration for connecting through a proxy server. The
ProxyConfig
object has the following properties:proxy_host
: Optional string specifying the proxy server hostproxy_port
: Optional number specifying the proxy server portproxy_auth
: Optional string for proxy authentication (format: “username:password”)proxy_protocol
: Optional string specifying the protocol (e.g., “http”, “https”)
Example Usage
Shutting Statsig Down
Because we batch and periodically flush events, some events may not have been sent when your app/server shuts down. To make sure all logged events are properly flushed, you should callshutdown()
before your app/server shuts down:
Local Overrides
Local Overrides are a way to override the values of gates, configs, experiments, and layers for testing purposes. This is useful for local development or testing scenarios where you want to force a specific value without having to change the configuration in the Statsig console.Client SDK Bootstrapping | SSR
If you are using the Statsig client SDK in a browser or mobile app, you can bootstrap the client SDK with the values from the server SDK to avoid a network request on the client. This is useful for server-side rendering (SSR) or when you want to reduce the number of network requests on the client.Client Initialize Response
The Python Core SDK provides a method to generate a client initialize response that can be used to bootstrap client SDKs without requiring network requests.Initialize Response Parameters
Initialize Response Parameters
The
get_client_initialize_response
method accepts the following parameters:user
:StatsigUser
- The user to generate the initialize response forhash
:Optional[str]
- Algorithm used for hashing gate/experiment names (default: ‘djb2’)client_sdk_key
:Optional[str]
- Client SDK key to use for initializationinclude_local_overrides
:Optional[bool]
- Whether to include local overrides in the response
Hash Algorithm
Hash Algorithm
The
hash
parameter specifies which algorithm to use for hashing gate and experiment names in the client initialize response. The default is 'djb2'
for better performance and smaller payload size.Available options:'djb2'
(default) - DJB2 hashing algorithm for better performance'sha256'
- SHA-256 hashing algorithm'none'
- No hashing applied
Client SDK Key
Client SDK Key
The
client_sdk_key
parameter lets you filter the response to only the specific feature gates, experiments, dynamic configs, layers, or parameter stores that a particular client key has access to - effectively letting you apply target apps.Local Overrides
Local Overrides
The
include_local_overrides
parameter determines whether to consider local overrides you’ve set when evaluating each config in the response.Full Code Example
Full Code Example
Below is a complete example of using the client initialize response to bootstrap a client SDK. Note that you may choose to parallelize or inline the initialize response data with other requests to your server, to eliminate additional requests and latency.
Response Format
Response Format
The method returns a JSON string containing the client initialize response. You’ll need to parse this string to access the data:The response includes:
feature_gates
: Feature gate evaluations for the userdynamic_configs
: Dynamic config and experiment evaluationslayer_configs
: Layer evaluationshas_updates
: Boolean indicating if there are updatestime
: Timestamp of the response
Persistent Storage
The Persistent Storage interface allows you to implement custom storage for user-specific configurations. This enables you to persist user assignments across sessions, ensuring consistent experiment groups even when the user returns later. This is particularly useful for client-side A/B testing where you want to ensure users always see the same variant.Data Store
The Data Store interface allows you to implement custom storage for Statsig configurations. This enables advanced caching strategies and integration with your preferred storage systems.Custom Output Logger
The Output Logger interface allows you to customize how the SDK logs messages. This enables integration with your own logging system and control over log verbosity.Output Logger
The Output Logger Provider interface allows you to customize how the SDK logs internal messages.Observability Client
The Observability Client interface allows you to monitor the health of the SDK by integrating with your own observability systems. This enables tracking metrics, errors, and performance data. For more information on the metrics emitted by Statsig SDKs, see the Monitoring documentation.FAQ
How do I run experiments for logged out users?
How do I run experiments for logged out users?
See the guide on device level experiments.
Reference
API Methods
check_gate(user: StatsigUser, gate_name: str, options: Optional[FeatureGateEvaluationOptions] = None) -> bool
get_dynamic_config(user: StatsigUser, config_name: str, options: Optional[DynamicConfigEvaluationOptions] = None) -> DynamicConfig
get_experiment(user: StatsigUser, experiment_name: str, options: Optional[ExperimentEvaluationOptions] = None) -> DynamicConfig
get_layer(user: StatsigUser, layer_name: str, options: Optional[LayerEvaluationOptions] = None) -> Layer
get_feature_gate(user: StatsigUser, gate_name: str, options: Optional[FeatureGateEvaluationOptions] = None) -> FeatureGate
get_parameter_store(user: StatsigUser, parameter_store_name: str, options: Optional[ParameterStoreEvaluationOptions] = None) -> ParameterStore
log_event(user: StatsigUser, event_name: str, value: Optional[Union[str, float]] = None, metadata: Optional[Dict[str, str]] = None) -> None
manually_log_gate_exposure(user: StatsigUser, gate_name: str) -> None
manually_log_dynamic_config_exposure(user: StatsigUser, config_name: str) -> None
manually_log_experiment_exposure(user: StatsigUser, experiment_name: str) -> None
manually_log_layer_parameter_exposure(user: StatsigUser, layer_name: str, parameter_name: str) -> None
get_client_initialize_response(user: StatsigUser, options: Optional[ClientInitializeResponseOptions] = None) -> ClientInitializeResponse
shutdown() -> AsyncResult[None]
Fields Needed Methods
The following methods return information about which user fields are needed for evaluation:get_gate_fields_needed(gate_name: str) -> List[str]
get_dynamic_config_fields_needed(config_name: str) -> List[str]
get_experiment_fields_needed(experiment_name: str) -> List[str]
get_layer_fields_needed(layer_name: str) -> List[str]