Enterprise customers with strict firewall policies may require whitelisting of all external API endpoints. To avoid asking each customer to whitelist Stigg’s API domains (api.stigg.io and edge.api.stigg.io), you can route Stigg SDK traffic through your 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:

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.

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