Caching improves latency and throughput by reducing the number of service calls the decision service makes to satisfy decision requests. A service is a good candidate for caching if service response values don’t change very often.

How service caching works

When the decision service requests information from a service, it caches the service response if the data has not already been cached. On subsequent service requests, instead of invoking the service again, the decision service uses the cached data until the cache expires.

The cache key includes a hash of service settings and interpolated attribute values. The decision service invokes the service and caches the service response under a new key when a value in the service request changes. For example, when there’s a new parameter in the request body, or an attribute value is resolving differently. The cache value contains the service response as strings.

PingOne Authorize maintains the service response in the cache for the period of time you define in the Time to live setting for a service. New cache keys are generated when you change any service setting and publish a new version. Returning to previous service settings might restore an older cache key and the previous version of the cache.


Cache entries are stored in memory and do not persist during a restart or outage.

Configuring service caching

You can configure cache settings for individual services when you add or edit a service. For more information, see Connecting a service.

You cannot clear the cache manually.


Service cache settings in PingOne Authorize override any cache control headers in the HTTP response. This can result in:

  • Caching when the headers indicate that the response shouldn’t be cached
  • A delay in retrieving an updated service response because the cache isn’t updated until it expires