Access enforcement at scale

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. The API exposes GET /api/v1/customers/{id}/entitlements and GET /api/v1/customers/{id}/entitlements/check for reading a customer’s entitlements, but at even moderate scale, sending those checks directly to the Stigg API introduces problems:

• Each check requires a network round-trip to Stigg
• Latency adds directly to your users’ request path
• Identical checks hit the network every time, because nothing between your application and Stigg caches the answer
• 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. To cache your REST entitlement checks, point your REST client’s base URL at the Sidecar. See Calling the Sidecar with the REST API. 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.
• Persistent — with Redis configured, the cache survives Sidecar restarts and is shared across Sidecar instances. See Persistent caching.
• Language-neutral — call it with any Stigg REST client or plain HTTP, or through the gRPC interface used by the Sidecar SDKs.

​

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