PingOne Platform APIs

Rate Limiting

We use rate limiting for all PingOne multi-tenant products. This ensures PingOne services' availability to all tenants is not degraded due to attacks, or to any one tenant’s excessive volume of requests or messages. Rate limits are defined per License, and shared by all environments assigned to that license. As opposed to PingOne usage entitlements that limit active user transactions per year, rate limiting affects the number of API requests you’re allowed to make per second. The rate limits can also simplify your load testing by reducing the necessary scope. Refer to Load Testing for more information. Refer also to PingOne Platform Limits for limits applied to services and their resources.

We’ve defined base rate limits that are intended to be sufficient for most tenants’ usage requirements. These base rate limits apply to all tenants. Refer to Base rate limits for details. However, through the Maximum Throughput Assurance program, you’re able to purchase higher rates if needed.

You can be alerted when traffic levels approach or exceed the limits of the license by:

  • Subscribing to rate limit alerts in the admin console. Refer to Alerts for more information.

  • Viewing events generated by the Audit service when thresholds are reached or exceeded. Refer to Audit for more information.

  • Viewing the API Usage Dashboard in the admin console to see peak usage history and trends. Refer to API Usage Dashboard for more information.

Requests that exceed the rate limits will be rejected with the 429 error, REQUEST_LIMITED. When this error occurs, the following header is returned in the response:

`Retry-After`
The delay in seconds indicating how long to wait before retrying the request.

Avoiding rate limiting issues

Some options to consider if you’re hitting rate limits:

  • Limit concurrent requests

    Check whether a client app is spawning an excessive number of concurrent requests or messages. This can cause the HTTP API requests to go over quota. To avoid this, set a limit on the number of threads used by the client app when these contribute to the total concurrent requests or messages, then adjust this limit for optimal throughput within the rate limit bounds.

  • Use message queues

    Message queues can be useful to control the rate of requests. Multiple operations can push messages to the queue, and you can implement throttlers to remain within the rate limits. If you hit a rate limit, you can adjust throttling, and resubmit the request.

  • Client-side throttling

    Implement client-side throttling to restrict the volume of requests or messages sent by the client app.

IP allow listing data model

Property Type Required? Mutable? Description

id

String

N/A

Read-only

The UUID of the rate limit configuration.

createdAt

String

N/A

Read-only

The date and time the rate limit configuration was created.

updatedAt

String

N/A

Read-only

The date and time the rate limit configuration was updated.

type

String

Required

Immutable

The type of rate limit configuration. Currently, the only type supported is "WHITELIST", indicating that the IP address in value is to be excluded from rate limiting.

value

String

Required

Immutable

The IP address (v4 or v6), or a CIDR range, for the IP address or addresses to be excluded.