> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stigg.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Network requirements and whitelisting

Enterprise environments with restrictive firewall rules may need to whitelist specific IP addresses and domains used by Stigg. This page consolidates all IPs and endpoints that may require whitelisting, and shows an alternative that avoids whitelisting altogether by routing SDK traffic through your own proxy.

## Whitelisting IPs and domains

### Production IP addresses

The following IP address is used across multiple services in the Stigg platform: `18.119.35.43`.

This IP address is used for production webhook event delivery, workflow executions, and any backend traffic originating from the Stigg production environment.

<Note>
  This IP address may change. We will notify affected customers ahead of time in case of an update.
</Note>

### API endpoints

If you're not routing traffic through a proxy, your firewall must allow outbound access to the following domains used by the Stigg SDKs and backend integrations:

* Core API: `https://api.stigg.io`
* Edge API: `https://edge.api.stigg.io`

If you're an enterprise customer using a firewall and want to avoid domain whitelisting, route SDK traffic through your own backend proxy instead — see [Routing through a proxy](#routing-through-a-proxy) below.

### AWS SQS endpoints

Stigg Sidecar and Stigg Proxy may communicate with Amazon SQS as part of workflow execution and event delivery. If your environment enforces outbound firewall rules, you must whitelist the AWS SQS regional endpoints relevant to your deployment.

For example, in **us-west-2**, the following domains should be allowed:

* `sqs.us-west-2.amazonaws.com`
* `*.queue.amazonaws.com`

<Note>
  AWS SQS does not guarantee static IPs. Always whitelist the domains, not the resolved IP address. Attempting to allowlist individual IPs (e.g., `3.239.232.80`) will not work reliably, since these IPs are subject to change without notice.

  If you are operating in another AWS region, adjust the domain accordingly (e.g., `sqs.eu-central-1.amazonaws.com`). See [AWS SQS Endpoints and Quotas](https://docs.aws.amazon.com/general/latest/gr/sqs.html) for the full list of supported regional domains.
</Note>

## Routing through a proxy

Rather than whitelisting Stigg's API domains (`api.stigg.io` and `edge.api.stigg.io`) for every customer, enterprise customers with strict firewall policies can route Stigg frontend SDK traffic through their own backend proxy.

This guide shows how to configure your frontend SDK and proxy server to forward requests to Stigg correctly.

### Overview

The Stigg frontend SDK communicates with two APIs:

* Core API: `https://api.stigg.io`
* Edge API: `https://edge.api.stigg.io`

To proxy these, you'll need:

* A backend server (proxy) that handles incoming SDK requests and forwards them to the correct Stigg endpoints.
* Configuration updates in the SDK to point to your proxy.
* Forwarding of specific headers to avoid authorization issues.

### Configure the Stigg frontend SDK

To route requests through your backend proxy, configure the Stigg frontend SDK with:

* `baseUri`: The proxy endpoint that forwards requests to `https://api.stigg.io`.
* `baseEdgeUri`: The proxy endpoint that forwards requests to `https://edge.api.stigg.io`.

For example:

```js theme={null}
import { createStiggClient } from '@stigg/js-client-sdk';

const stiggClient = createStiggClient({
  apiKey: 'YOUR_API_KEY',
  customerId: 'CUSTOMER_ID',
  baseUri: 'https://your-proxy.example.com/core',
  baseEdgeUri: 'https://your-proxy.example.com/edge',
});
```

These settings ensure that all SDK traffic is directed through your infrastructure rather than directly to Stigg's servers.

If you're proxying frontend SDK requests through your own infrastructure, no additional IPs need to be whitelisted except your own. The proxy server should be configured to forward:

* `/core → https://api.stigg.io`
* `/edge → https://edge.api.stigg.io`

### Requirements for the proxy server

Once the frontend SDK is configured to send traffic to your proxy, the proxy server is responsible for correctly forwarding those requests to Stigg. It must distinguish between two types of traffic: standard API requests and edge-optimized requests.

Requests targeting the Core API should be forwarded from your proxy to `https://api.stigg.io`. Similarly, any requests related to the Edge API must be forwarded to `https://edge.api.stigg.io`. This typically involves exposing two distinct paths or routes on your proxy, one for each upstream destination.

In addition to routing, the proxy must preserve the full set of headers sent by the Stigg SDK. Specifically, the following headers must be included in the forwarded request without modification:

* `X-API-KEY`: Used to authenticate the SDK with Stigg
* `X-API-VERSION`: Specifies which API version the SDK is using
* `X-CUSTOMER-KEY`: Identifies the customer associated with the request

If any of these headers are missing, altered, or stripped out, the request may be rejected by Stigg's backend, most commonly with a 403 Forbidden response.

### Performance considerations

Routing SDK traffic through a proxy server introduces a slight increase in latency due to the extra network hop. In most cases, this added delay is negligible. However, if the proxy is hosted in a region that is geographically distant from your end users, the latency impact can become more noticeable, particularly for time-sensitive operations.

The Edge API is designed specifically to reduce this type of latency by routing requests through regionally optimized endpoints. When you proxy Edge API traffic through your own infrastructure, you effectively remove this regional advantage. All requests will be funneled through your proxy's location, regardless of where the end users are located, which may degrade performance, especially for globally distributed applications.

### Disabling the Edge API

Although it is technically possible to disable the Edge API in the SDK configuration, this should only be done in rare cases where proxying edge traffic is not feasible. Disabling the Edge API forces all traffic to use the Core API, which can significantly impact responsiveness and eliminate the geographic optimizations that the Edge layer provides. As such, this approach is not recommended unless absolutely necessary.


## Related topics

- [Networking, security, and data flow](/documentation/high-availability-and-scale/byoc/networking-and-security.md)
- [Bring Your Own Cloud (BYOC)](/documentation/high-availability-and-scale/byoc/overview.md)
- [MongoDB](/documentation/importing-and-exporting-data/export/mongodb.md)
- [Import my Zuora catalog into Stigg](/documentation/native-integrations/billing/zuora/import-zuora-catalog-into-stigg.md)
- [AI Terminal](/api-and-sdks/ai-terminal.md)