# Server SDKs

> For AI agents: a documentation index is available at [/llms.txt](/llms.txt). Append `.md` to any page URL for markdown, or send `Accept: text/markdown`.

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

![Server SDKs](https://docs.statsig.com/images/server/introduction/169563936-121cb75e-37e5-491f-8bb1-2d853c2e04b8.png)

### 1. Initialization

- The server SDK's `initialize` call takes the **server SDK key** and makes a network request to Statsig servers. The request fetches 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**](https://docs.statsig.com/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**](https://docs.statsig.com/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**](https://docs.statsig.com/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 of the check, 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. Calling `shutdown` at exit 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.
- Statsig updates the **Users** and **Checks** charts in the **Diagnostics** tab hourly. Statsig updates the **Metrics Lift** panel in experiment **Results** daily around 9am PST.

#### Updating experiment configuration

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

> **Info:**
>
> **Why is `StatsigUser` with a `userID` required for server SDKs?**
>
> Refer to [UserID Requirements](https://docs.statsig.com/sdks/user#why-is-an-id-always-required-for-server-sdks) to understand why having a unique `userID` in the [**StatsigUser**](https://docs.statsig.com/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. Including a default value ensures your application falls back to that value for a parameter you haven't yet configured in an experiment, layer, or dynamic config in the Statsig console. By default, Statsig returns _false_ when you check a gate you haven't yet configured.

### 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**. Statsig updates the **Metrics Lift** panel in the experiment **Results** tab daily around 9am PST.

> **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.

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

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

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