## Direct initialization API access for server SDKs, October 31, 2025

#### What's changing

Until mid-2024, Statsig's Server SDKs downloaded configuration values directly from Statsig servers on startup. Statsig now hosts these configuration files on a secure CDN (Cloudflare), which reduces initialization time and increases reliability.

Direct API access is deprecated. It's only available in outdated SDK versions. All customers must stop using these SDK versions and upgrade.

#### Change required

The only change required is a minor SDK version bump. You don't need any code changes. Bump your SDK version to at least:

* **go-sdk** 1.30.3
* **java-server** 1.9.0
* **py-server** 0.28.0
* **ruby-server** 1.29.0
* **statsig-node** 5.25.0
* **.NET** 2.4.1
* **Node-lite** 0.5.0
* **PHP** 3.7.2

Make this change by October 31st, 2025.

{% callout type="note" %}
Only a more recent version of the PHP and .NET SDKs supports CDN access, so Statsig won't strictly enforce an upgrade for those 2 SDKs. Upgrade as soon as possible.
{% /callout %}

## New method for country resolution

Starting December 9th, 2024, Statsig uses a more accurate method of resolving IP addresses to country codes in client SDKs, which may result in different gate behavior for some users. For country resolution in both Client and Server SDKs, Statsig uses a [homegrown package](https://github.com/statsig-io/ip3country) that lacks IPv6 support. To resolve countries without increasing SDK size, Statsig uses the cloud provider's country resolution when serving requests to the `/initialize` endpoint.

### Potential changes in client evaluations

This may result in different evaluations for some client-side checks. The new method is more accurate and complete. You may see more users passing country rules, because the new method resolves countries for IPv6 users, who now represent a large share of many customers' user base.

### Conflicts with server-side checks

If you check some configs on both the client and server side, a small number of users may pass targeting on the client but fail on the server, or vice versa. Server-side country resolution continues to use [IP3Country](https://github.com/statsig-io/ip3country) when a country isn't explicitly set on the `StatsigUser` object. To avoid conflicts, use your cloud provider's country resolution (often available in a load balancer) and set the result as the `country` field on the `StatsigUser` object. This applies to evaluations for gates, configs, experiments, and layers, and also to `getClientInitializeResponse` when generating the payload for a client SDK.

## Async evaluation functions

#### Reason

Statsig originally designed Server SDKs for maximum backward compatibility. If a Server SDK didn't support an operator or configuration, it fell back to Statsig servers to ensure a valid result, which required asynchronous top-level evaluation functions.

In practice, you rarely need this fallback. Newer releases remove the asynchronous functions.

#### Example

```java
var result = await Statsig.checkGate("my_gate"); // Bad
// For node v6.0.0
var result = Statsig.checkGate("my_gate") // Good
// For .Net and Java
var result = Statsig.checkGateSync("my_gate"); // Good

```

#### SDKs

.NET Server - [v1.20.0](https://github.com/statsig-io/dotnet-sdk/releases/tag/v1.20.0)

NodeJS Server - [v5.10.0](https://github.com/statsig-io/node-js-server-sdk/releases/tag/v5.10.0)

Java/Kotlin Server - [v1.12.0](https://github.com/statsig-io/java-server-sdk/releases/tag/v1.12.0)