This section provides documentation on the API proxy options available when using Statsig.

## Why use an API proxy

Reasons to implement an API proxy for Statsig network requests:

1. **Mitigate tracking blocker impact**: Reduce the effect of tracking blockers on Statsig API usage. Default Statsig endpoints are commonly blocked by tracking blockers, so using a custom proxy with product-specific endpoint names is essential for reliable data collection.
2. **Meet security requirements**: Comply with internal network security and topology standards.
3. **Enhance API availability**: Improve API availability guarantees within your internal network boundary.

## API proxy deployment options

You can deploy API proxies in various forms, each with its own advantages and considerations. The choice between a managed service and a self-hosted solution, or deploying outside versus inside your network, depends on your needs.

The following options are available:

For both server SDKs and client SDKs:

* [Custom Proxy](/infrastructure/api_proxy/custom_proxy): A fully customizable proxy that you own and operate in your environment.
* [Managed Proxy](/infrastructure/api_proxy/managed-proxy): A lightweight, Statsig-owned proxy that works by default without additional configuration.

For server SDKs only:

* [Forward Proxy](/server/concepts/forward_proxy): A Statsig-built proxy designed for deployment within your own environment.

Choose the option that best fits your infrastructure requirements and operational preferences. If you have questions, join the [Statsig Slack channel](https://www.statsig.com/slack).