Skip to main content
Every time your application decides whether a customer can use a feature, it runs an entitlement check. Because these checks sit on the critical path of your product, Stigg is built so that they stay fast and keep working even when the Stigg API can’t be reached. This section covers what entitlements are, how to check them in your application, and how to deploy Stigg for the availability and scale you need.

The request path

  1. Your application asks the SDK (or the Sidecar) whether a customer has access to a feature.
  2. If the customer’s entitlements are cached, the answer comes straight from the cache, without a network call. The Node.js SDK and the Sidecar keep an in-memory cache, which stays current through polling or real-time updates. Other backend SDKs call the Stigg API on every check.
  3. Otherwise, the SDK fetches the entitlements from the Stigg API, which runs at the edge location closest to your servers.
See Caching for how the in-memory and persistent caches work.

When the Stigg API is unreachable

Stigg keeps your application running through network issues and outages:
  • Cached entitlements keep answering checks while the SDK retries in the background.
  • Fallback values decide access when there’s no cached data. You can set them globally or per feature. See Fallback strategy.
  • Buffered usage is held by the SDK and reported once connectivity returns. See Errors, retries, and usage buffering.

Choosing a setup