Skip to main content
Stigg enforces rate limits on REST API endpoints to protect platform stability and prevent unintended overload from misconfigured clients or retry loops. Two kinds of limits apply, depending on the endpoint:
  • Entity-level limits — mutation endpoints are limited per entity (customer, subscription, or customer+resource), so repeated calls against one entity can’t starve out calls to others. Each entity has its own independent bucket: a customer-based operation is keyed on customerId, a subscription-based operation on subscriptionId, and a customer+resource operation on customerId:resourceId.
  • Shared Edge limits — paywall and entitlement reads are always served through the Edge API, a separate low-latency layer, and share a single rate-limit bucket per API key across all of those endpoints (not per-endpoint). This includes the REST entitlement-check endpoints below, REST SDK entitlement checks, and the raw edge.api.stigg.io JSON endpoints used internally by the SDKs — there is no separate “Edge API” surface to track independently.

​
Behavior

  • When the limit is exceeded, Stigg returns a 429 response: {"error":"rate_limit_exceeded","message":"Too many requests"}
  • No Retry-After header is included in the response
  • The /health endpoint is exempt from rate limiting
  • Entity-level limits apply even across different endpoints or HTTP methods targeting the same entity
If higher rate limits are required, please contact Stigg Support