About rate limiting

In order to protect product application performance in large, multi-tenant clusters, Passfort has introduced a rate limit on profile creation, profile audit report exports, and collected data updates.

Currently, both the POST /4.0/profiles/{profile_id}/collected_data and POST /4.0/profiles endpoints are rate-limited at 10,000 requests per hour. This is equivalent to creating approximately 2.7 profiles per second. The GET /4.0/profiles/{profile_id}/audit/pdf_report endpoint is rate-limited at 0.75 requests per second.

If you hit the rate limit, you won’t be prevented from creating profiles or updating collected data. However, you’ll be prevented from making requests faster than the rate limit allows.

Note that:

Rate limits are only applied to requests made using API keys.
Rate limits are only applied to the specific endpoints discussed in this article, and these limits are applied separately. This means that rate limits for one endpoint won't affect other rate-limited endpoints, as they have independent quotas and don’t restrict access to other endpoints when a limit is hit.

Passfort’s customer API implements a rate-limiting algorithm called GCRA. GCRA rate limiting uses buckets that can hold up to a certain number of cells, also known as the burst limit. Each bucket starts at the burst limit, and requests consume one or more cells based on their cost. The bucket is replenished continually with cells at a rate that is defined by a desired rate limit for every period of the bucket that passes. The state of the bucket can be stored by knowing the rate limit, burst limit, period, and cost values, as well as the time at which the bucket will fully recover, known in the algorithm as t_at. The resulting rate limiter gives a rate limit equal to rate limit/period under sustained use, but allows rate-limited users to otherwise exceed their normal rate limits for defined larger bursts, which then recovers over idle periods to average out to the same rate limit. GCRA rate limiters are saturating; repeatedly hitting the rate limit does not reduce the rate limit. However, if the burst limit is larger than the rate limit, the peak throughput will be reduced until the bucket is fully replenished.

How rate limits are exposed through the API

Rate-limited endpoints function identically to normal endpoints, with the following differences:

Additional headers are present in responses with rate-limiting information exposed:
- X-RateLimit-Remaining - This is the current number of requests remaining before the rate limit is reached.
- X-RateLimit-Reset-Secs - This is the number of seconds until the rate limit bucket is fully replenished to the burst limit.
- X-RateLimit-Reset - This is a date and time, in the format specified by RFC 2822, section 3.3, for example, Thu, 27 Jan 2022 11:30:22 +0000). This is X-RateLimit-Reset-Secs after the current time when the request was received. This format was implemented for human readability.

When using rate limiting information, using header X-RateLimit-Reset-Secs is recommended over using X-RateLimit-Reset.

Once the entity hits a rate limit, the endpoint will stop responding to requests normally and return the status code: 429 Too Many Requests.

Once the rate limit is reached:

X-RateLimit-Remaining will be 0 to indicate that the rate limit quota has been used up.
- Further rate-limiting headers are present in rate-limited request responses:
  - X-RateLimit-Retry-Secs - This is the minimum number of seconds until the rate limiter can allow another request.
  - X-RateLimit-Retry - As with X-RateLimit-Reset, this is a human-readable date which is X-RateLimit-Retry-Secs after the time of the request.

Additional information

Create profiles using the API

In this section:

About rate limiting

How rate limits are exposed through the API

Additional information

Search results