---
title: Enrich SDK users with Forward Proxy
description: "Understand how Forward Proxy supplies ID list memberships before local SDK evaluation, including membership freshness and failure behavior."
product: general
lang: en
token_estimate: 842
---
# Enrich SDK users with Forward Proxy

With standard SDK ID list targeting, each application process downloads and stores ID lists in memory. Large lists or many application replicas increase total memory use. Forward Proxy user enrichment stores shared list data in Redis and fetches a user's memberships before local evaluation.

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

Use enrichment to reduce application memory use or share list storage across processes. Building each enriched user requires an asynchronous network request. Use standard SDK targeting when list data fits each process's memory budget and you want to build users without that request. Evaluation remains local with either approach.

Both standard SDK targeting and Forward Proxy enrichment require Statsig Support enablement for lists above 10 million IDs. Enrichment doesn't increase the project's ID list allowance or enable a 100-million-ID list automatically.

## How enrichment works

Enrichment requires a compatible early-access SDK build and a [Forward Proxy deployment](https://docs.statsig.com/server/concepts/forward-proxy-id-list-enrichment) with synchronized ID list data. For the Rust integration, follow [ID list enrichment in the Rust SDK](https://docs.statsig.com/server-core/rust-core#enrich-users-for-forward-proxy-id-list-evaluation).

Enrichment adds an asynchronous network step before evaluation:

1. Your application provides the user's ID and any custom IDs to an enrichment builder.
2. The builder requests memberships from Forward Proxy using the project's server secret key.
3. The proxy returns the matching ID lists for those IDs, limited to the lists available to that key.
4. The builder attaches the memberships to a standard SDK user. Your application passes that user to its usual evaluation methods.

Gate, config, experiment, and layer evaluation intentionally stays synchronous and entirely compute-bound. Resolving memberships beforehand avoids network I/O and additional expensive operations across language bindings during evaluation. This separation keeps evaluation performance predictable.

Config-spec fetching and event delivery keep their normal SDK lifecycles, separate from enrichment.

## Membership snapshots and freshness

An enriched user holds a snapshot of memberships from the enrichment request. Reuse that user across evaluations without another network request. Existing enriched users don't update automatically; build a new enriched user when you need refreshed memberships.

ID list changes take time to synchronize. A user newly added to an ID list may still appear as a non-member. A user removed from an ID list may remain a member until synchronization completes. A successful lookup doesn't guarantee that the memberships reflect the latest list changes.

## Handle enrichment failures

A successful lookup can return no memberships. An enrichment failure, such as a timeout or unavailable proxy, means the builder couldn't determine memberships and returns no user.

Choose your application's response to a failed build explicitly. Substituting empty memberships or an unenriched user can make targeting treat the user as a non-member. Config-spec fallback to the Statsig API doesn't recover enrichment failures.