Stigg · Rate Limits

Stigg Rate Limits

Stigg enforces per-operation rate limits on its GraphQL API (and REST API). High-read operations allow up to 6000 requests per minute, mid-tier read operations 3000 per minute, and mutations 250 per minute. Event reporting uses a per-second window. Entity-level limits prevent concurrent mutation storms at 30 calls per minute per entity identifier. Limits are enforced per API key.

Stigg Rate Limits is the machine-readable rate-limit profile for Stigg on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 5 rate-limit definitions, measuring requests and bulk-requests.

The profile also includes 4 backoff/retry policies defined and response codes documented for throttled.

Tagged areas include FinOps, Pricing, Billing, Entitlements, and Usage-Based Billing.

5 Limits Throttle: 429
FinOpsPricingBillingEntitlementsUsage-Based BillingSaaSRate Limiting

Limits

Edge / Public Read Operations api-key
requests
6000
Highest-traffic read paths served via Edge CDN.
In-App Read Operations api-key
requests
3000
Mutation Operations api-key
requests
250
Event Reporting api-key
bulk-requests
1000
reportEvent uses a per-second window rather than per-minute. Limit is per bulk batch size.
Per-Entity Mutation Limit entity
requests
30
Prevents repeated concurrent mutations on a single customer or subscription entity. Applies to customerId, subscriptionId, and customerId:resourceId combinations.

Policies

Per-Endpoint Limits
Stigg sets distinct rate limits per operation rather than a single global account ceiling.
Per-Entity Limits
In addition to global per-endpoint limits, each entity (customer, subscription, resource) has its own 30/min concurrent mutation cap to prevent stampede scenarios.
Backoff Strategy
Clients receiving HTTP 429 should back off and retry; exponential backoff with jitter is recommended.
Limit Escalation
Higher rate limits are available upon request by contacting support@stigg.io.

Sources