Statsig server SDKs allow you to run experiments for server-side functionality such as APIs, algorithms, configurations, and infrastructure improvements. The server SDKs evaluate feature gates, dynamic configurations, and experiments locally on your application server.

Implementing an experiment using a Statsig server SDK consists of three phases:

1. Initialization
2. Checking an Experiment
3. Logging Custom Events

{% figure %}
![Server SDKs](/images/server/introduction/169563936-121cb75e-37e5-491f-8bb1-2d853c2e04b8.png)
{% /figure %}

### 1. Initialization

* The server SDK's `initialize` call takes the **server SDK key** and makes a network request to Statsig servers to fetch all the rule sets (experiments, feature gates, and configurations) to your application server.

* The SDK loads all required configurations to enable local evaluation of experiments, gates, and configs without additional network requests.

### 2. Checking an Experiment

* After the `initialize` call completes, the `getExperiment` call with a [**StatsigUser**](/sdks/user) object synchronously returns the variant assigned to the user (you define these parameters when you set up an experiment on the Statsig console). Use the returned `config` object to `get` the value of the parameters required to implement the experiment variant.

* If your experiment is part of a Layer, the `getLayer` call with a [**StatsigUser**](/sdks/user) returns the variant assigned to the user. Use the returned `layer` object to `get` the value of the parameters required to implement the experiment variant.

* The `checkGate` call with a [**StatsigUser**](/sdks/user) returns *true* if the user passes the feature gate rules configured on the Statsig console, and *false* otherwise.

* The `getConfig` call returns the dynamic configuration based on the rules configured to target your users. Use the returned `config` object to `get` the value of the parameters required to serve a dynamically configured app experience.

* All of the above (`checkGate`, `getExperiment`, `getLayer`, and `getConfig`) log an exposure at the time the check is made, before returning a value to the caller.

* The server SDK automatically flushes all accumulated exposure checks and events to Statsig servers every 60 seconds.

* Call `shutdown` to force a flush of accumulated exposure checks to Statsig servers. Call `shutdown` when the application is about to exit: this is especially important for short-lived processes like serverless functions.

* Verify that the Statsig console records exposure events by checking the live **Exposure Stream** under the **Diagnostics** tab of your experiment.

* The **Users** and **Checks** charts in the **Diagnostics** tab are updated hourly. The **Metrics Lift** panel in experiment **Results** is updated daily around 9am PST.

#### Updating experiment configuration

* The SDK automatically polls Statsig servers every 10 seconds (configurable) to fetch updated rule sets.

{% callout type="info" %}
**Why is `StatsigUser` with a `userID` required for server SDKs?**

Refer to [UserID Requirements](/sdks/user#why-is-an-id-always-required-for-server-sdks) to understand why having a unique `userID` in the [**StatsigUser**](/sdks/user) object is required for server SDK usage.

**Setting Default Parameter Values**

Include a default value when you make the `get` call to fetch a parameter value from the returned `config` object. This ensures your application falls back to the default value for a parameter that has not yet been configured in an experiment, layer, or dynamic config in the Statsig console. By default, Statsig returns *false* when you check a gate that has not yet been configured.
{% /callout %}

### 3. Logging Custom Events

* The server SDK's `logEvent` call takes a custom event to record and analyze the impact of the experiment on your users.

* The server SDK automatically flushes all accumulated logged custom events to Statsig servers every 60 seconds.

* Statsig uses these custom events to compute metrics as part of your experiment **Results**. The **Metrics Lift** panel in the experiment **Results** tab is updated daily around 9am PST.

{% callout type="info" %}
To test your experiment in development or staging environments, set the environment tier in the `initialize` call. Verify that exposure checks are working by switching the toggle to *Show non-production logs* in the **Exposure Stream** under the **Diagnostics** tab for your experiment in the Statsig console. By default, the **Exposure Stream** shows exposure checks logged in production environments.

When testing in development or staging environments, target specific team members to see a specific variant by adding them to the override list of a rule or variant group using the **Manage Overrides** option.
{% /callout %}

To start integrating, go to the technical docs by language:

* [Node.js](/server/nodejsServerSDK)
* [Java](/server/java)
* [Python](/server/pythonSDK)
* [Go](/server/go)
* [Ruby](/server/ruby)
* [C# (.NET Core)](/server-core/dotnet-core)
* [PHP](/server/php)
* [C++](/server/cpp)
* [Rust](/server/rust)

For questions, join the Statsig engineering and product team on the [Statsig Slack channel](https://statsig.com/slack).