Strivacity implements rate limiting across all of its APIs, on a per instance basis. Each API path has its own independent quota, meaning the limits for one path do not affect the usage of another. Rate limits may vary depending on the type of API that is being used.

In general, APIs will respond with HTTP 429 Too Many Requests when the rate limit has been reached.

If the rate limit is being reached, brands should stop using the API until the rate limit period has expired.

Example daily request capacity:

• /oauth2/token and /userinfo: up to 14,400,000 requests over a 24-hour period per instance in total and up to 8,640,000 requests over a 24-hour period per a single IP.

If a higher rate limit is required, contact us at [email protected].

Rate limits

Strivacity implements the following limits for production instances of Strivacity.

📘

The rate-limiting quotas are applied independently to each API path listed in the table.

Rate limit response headers

API responses include three rate-limit header types:

• X-Ratelimit-Limit
• X-Ratelimit-Remaining
• X-Ratelimit-Reset

You may see each of these headers multiple times in a single response, but these are not duplicates. They represent different rate-limit buckets applied at the same time (for example: per instance per minute, per instance per second, per IP per minute, per IP per second).

The headers must be interpreted in the following order:

The first X-Ratelimit-Limit corresponds to the first X-Ratelimit-Remaining and the first X-Ratelimit-Reset. The second set corresponds to each other, and so on.

X-Ratelimit-Limit

Indicates the configured quota for a specific bucket.

Example:

X-Ratelimit-Limit: 10000, 10000;w=60
X-Ratelimit-Limit: 300, 300;w=1
X-Ratelimit-Limit: 100, 100;w=60
X-Ratelimit-Limit: 10, 10;w=1

This means:

• 10,000 requests per 60 seconds (instance-level, per minute)
• 300 requests per second (instance-level)
• 100 requests per 60 seconds (per IP)
• 10 requests per second (per IP)

The w parameter indicates the time window in seconds.

X-Ratelimit-Remaining

Indicates how many requests are still available in each corresponding bucket.

Example:

X-Ratelimit-Remaining: 9999
X-Ratelimit-Remaining: 299
X-Ratelimit-Remaining: 99
X-Ratelimit-Remaining: 9

These values match the limits above in the same order.

For example, after one request:

• 9,999 remaining from the 10,000/minute bucket
• 299 remaining from the 300/second bucket
• 99 remaining from the 100/minute per-IP bucket
• 9 remaining from the 10/second per-IP bucket

X-Ratelimit-Reset

Indicates how many seconds remain before the bucket resets.

Example:

X-Ratelimit-Reset: 22
X-Ratelimit-Reset: 1
X-Ratelimit-Reset: 22
X-Ratelimit-Reset: 1

This means:

• The minute-based buckets will reset in 22 seconds.
• The per-second buckets will reset in 1 second.

When a bucket reaches zero (X-Ratelimit-Remaining: 0), requests exceeding that limit will receive HTTP 429 Too Many Requests. Clients should wait for the corresponding X-Ratelimit-Reset value before retrying.

How to process the headers

1. Read all X-Ratelimit-Limit headers.
2. Match them by position with X-Ratelimit-Remaining and X-Ratelimit-Reset.
3. Monitor the bucket closest to exhaustion.
4. If a remaining value reaches 0, pause requests for the number of seconds indicated by its matching Reset header.

All buckets apply simultaneously, and exceeding any one of them can trigger a 429 response.