Skip to main content
The REST API is the right tool for provisioning operations — creating customers, managing subscriptions, reporting usage. These are write-heavy, low-frequency operations that fit naturally into a REST request/response model. Access checks are different. Entitlement checks happen on every authenticated request in your product: gating feature access, enforcing usage limits, checking plan-based permissions. At even moderate scale, routing those checks through the REST API introduces problems:
  • Each check requires a network round-trip to api.stigg.io
  • Latency adds directly to your users’ request path
  • There is no request-level caching — identical checks hit the network every time
  • The API is designed for provisioning mutations, not sub-millisecond read throughput

​
The Sidecar

For production access checks, Stigg provides the Sidecar: a lightweight service that runs alongside your application and serves entitlement evaluations from a local cache. Key characteristics:
  • Low latency — cached reads resolve in-process without a network call. On a cache miss, the Sidecar fetches from the Stigg Edge API (~100 ms) and populates the cache for subsequent requests.
  • Real-time updates — the Sidecar subscribes to Stigg’s event stream and refreshes cached entitlements and usage automatically when plans or subscriptions change.
  • Fail-safe — if the upstream Stigg API becomes unreachable, the Sidecar continues serving reads from its cache. If the cache is also unavailable, it falls back to configurable static default values.
  • Language-neutral — the Sidecar exposes a gRPC interface defined with Protocol Buffers, so any language can call it.
Node.js applications do not need the Sidecar. The Node.js SDK provides full feature parity — including low-latency entitlement checks, local caching, and real-time updates — natively in-process.

​
Deployment options

The Sidecar can run in two configurations: Sidecar pattern — one Sidecar container per application instance, co-located in the same network namespace (e.g., the same Kubernetes Pod). Requests stay on localhost with no external hops. Standalone service — a single shared Sidecar instance that multiple application instances access over a private network port. Simpler to operate, but adds a small internal network hop and shares cache miss load across callers. See Sidecar Architecture for diagrams and caching configuration details.

​
Getting started

Sidecar Overview

Understand fail-safe design, latency guarantees, and isolation properties

Running the Sidecar

Docker setup, environment variables, and health endpoints

Sidecar SDK

Install and call the Sidecar from Python, Ruby, Go, Java, or .NET

Production guide

Scaling, monitoring, alerting, and troubleshooting