Skip to main content
Stigg enforces entity-level rate limits on REST API endpoints to protect platform stability and prevent unintended overload scenarios caused by misconfigured clients or retry loops.
Paywall and entitlement reads are served by the Edge API, which has its own shared rate limit.

​
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 target different endpoints
  • The calls use different HTTP methods

​
Subscription endpoints

​
Customer endpoints