Skip to main content
Stigg enforces rate limits to protect platform stability and prevent unintended overload from misconfigured clients or retry loops. Two kinds of limits can apply to a given operation, and a request must pass both when both are listed:
  • Operation-level limits — how many times a specific GraphQL operation can be called per minute, regardless of which customer or subscription is targeted. Some read operations at 6,000 / min are served through the Edge API, a separate low-latency layer, and share a single bucket per API key across all of those operations instead of having their own individual limit.
  • Entity-level limits — mutations are additionally 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. This applies even if the calls use different mutations or the operation-level limit hasn’t been reached.
reportEvent supports up to 100,000 events per second on Stigg Cloud. For higher limits, see BYOC below or contact Stigg Support.

Need 1M+ events/second? Join the BYOC Early Access

Bring Your Own Cloud (BYOC) deploys Stigg’s ingestion layer in your own infrastructure, removing rate-limit ceilings and keeping event data in your cloud. Contact us to join the Early Access program.

​
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
If higher rate limits are required, please contact Stigg Support