## Using PassFort

In order to protect application performance in large, multi-tenant clusters, PassFort has introduced a rate limit on profile creation 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.

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.

### 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.