Rate Limits

Stigg enforces rate limits to protect platform stability and prevent unintended overload scenarios caused by misconfigured clients or retry loops. Rate limiting is applied at two levels:

• Global endpoint rate limits – how many times a specific operation can be called per minute.
• Entity-level rate limits – how many times the same entity (customer, subscription, or customer resource) can be mutated within a time window.

Both limits apply simultaneously. A request must pass both to succeed.

​

Global endpoint rate limits

Global rate limits apply per operation, regardless of which customer or subscription is being targeted.

​

Entity-level rate limits (resource protection)

These limits exist to prevent repeated concurrent mutations on the same entity, which can cause:

• Parallel processing contention
• Unnecessary retries
• Backend instability
• Incident-level load amplification

​

Entity types

Entity-level rate limits are enforced for the following entities:

• Customer
• Subscription
• Customer resource (customer and resource combination)

Each entity has its own rate limit bucket, independent of other entities. When a request mutates state, it is routed to a bucket based on the entity it targets:

• Customer-based operations → customerId
• Subscription-based operations → subscriptionId
• Customer and resource operations → customerId:resourceId

​

Example

If the entity-level limit is 30 calls per minute:

• Calling cancelSubscription 30 times per minute for the same subscription ID is allowed
• The 31st call for that subscription will fail
• Calls for other subscriptions are unaffected
• Calls for other customers are unaffected

This applies even if:

• The calls use different GraphQL mutations
• The global endpoint rate limit has not been reached

​

GraphQL operations with entity-level rate limits

The following GraphQL mutations are subject to entity-level rate limiting. Each mutation is limited based on the specific entity key it mutates.