Rate Limits

• Endpoint-level limits set how many times a specific endpoint can be called with one API key, regardless of which customer or subscription is targeted. This includes governance management and usage reporting endpoints.
• Customer and subscription limits apply to the endpoints below whose limit is per customer, per subscription, or per customer + resource, so repeated calls against one of them can’t starve out calls to others. Each 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 cover paywall and entitlement reads. These 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, governance checks, and REST SDK entitlement checks.

Behavior

• When an endpoint-level or customer and subscription limit is exceeded, Stigg returns a 429 response with a Retry-After header that gives the seconds until the limit resets. Successful responses carry X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers for the endpoint-level limit
• When a shared Edge limit is exceeded, Stigg returns a 429 response: {"error":"rate_limit_exceeded","message":"Too many requests"}. Retry with exponential backoff
• The /health endpoint is exempt from rate limiting
• Customer and subscription limits apply even across different endpoints or HTTP methods targeting the same customer or subscription