Caching in IBM API Connect (v5, 2018.x, v10.x)

Some of our most used API’s return data that doesn’t change very often. To reduce the number of calls to the backend and improve the latency of those API’s we use caching.

Caching in IBM API Connect can be done on invoke-policies that make a call to a backend service (http/https). The result of the API itself cannot be cached, only the response of the invoke is cached.

For this reason, the way we handle caching in IBM API Connect is by adding an extra API layer that does the caching between the API that needs to be cached and the consumer. Often this extra layer already exists (for example for managing security or client-specific mappings). For clarity I will refer to the original API as the base API and to the API in the extra consumer-specific layer as the proxy-API.

What we will do to implement caching is setting cache control headers in every response of the base API service and implement a caching strategy on the level of the API-proxies, that are unique for every consumer. This also makes sense, since not every consumer wants to use caching. IBM API Connect supports the Cache-Control response headers as defined in RFC7234 (

There are some restrictions to the use of the cache. The underlying Datapower runtime only supports a shared cache. This means that API’s that require authentication (Authorization header) cannot be cached.

Base API

In the base API we will set a cache-control response header. The value will contain the time to live for the specific cache in seconds. This TTL is the maximum lifetime that the response should be cached by its clients.

Example below for a cache with a lifetime of 24hours

Cache-Control: public, max-age=86400

API Proxy

Cache response parameter

Controlling caching on invoke/proxy policy in API Manager is done with the cache response parameter. There are 3 possible values:

  • Protocol: This means that the policy will look at the Cache-Control response headers as defined in RFC7234 ( If the response indicates that caching is possible, the gateway responds to all waiting requests with the cached resource. If the response indicates that caching is not possible, the gateway sends all waiting requests to the target URL.
  • No cache: Responses from the target URL are not cached on the gateway regardless of any caching headers returned.
  • Time to live: This option is similar to the Protocol option except it allows you to specify the amount of time in seconds that you want the successful response from the invoke or proxy to remain in the cache. This does not overwrite the max-age value returned from the base API, so only use this option if you want to make the time to live shorter than what the base API returns.

We will use the 1st and 3rd option in case we want to implement caching. If we reuse the time to live from the underlying API’s response, we go for the first option.

In case we want to have a shorter lifetime for the cache, we can use the time to live option. We should never define a longer lifetime for the cache than the value defined in the response headers of the base API.

Other possible optional cache-options on the invoke

  • Cache key: Use this if you want to use a unique identifier for the call you want to cache. If not set, the URI is used as caching key.
  • Cache putpost response: Set this to ‘true’ if you also want to cache PUT/POST responses. By default this is set to ‘false’.


You can check if the cache is working by logging into the Datapower domain of the API proxy and going to the ‘Document Status’ page. This page lists all cached documents, including the cached pages for IBM API Connect. (the other pages can be ignored they are part of the internal working of APIC)


Author: Tim Rombouts

Samuel Vandecasteele

Samuel Vandecasteele

Curious to know more about this topic?

Working at i8c

i8c is a system integrator that strives for an informal atmosphere between its employees, who have an average age of approx 30 years old. We invest a lot of effort in the professional development of each individual, through a direct connection between the consultants and the management (no multiple layers of middle management). We are based in Kontich, near Antwerp, but our customers are mainly located in the triangle Ghent-Antwerp-Brussels and belong to the top 500 companies in Belgium (Securex, Electrabel, UCB, etc…).

Quality Assurance

i8c is committed to delivering quality services and providing customer satisfaction. That’s why we invested in the introduction of a Quality Management System, which resulted in our ISO9001:2000 certification. This guarantees that we will meet your expectations, as a reliable, efficient and mature partner for your SOA & integration projects.

i8c - ISO9001-2015

Also worth reading

AWS AppFlow: Streamlining SaaS Integrations with AWS Services

In today’s digital world, organizations are constantly looking for ways to streamline their workflows and improve their data management processes. One of the key challenges that organizations face is integrating their various software as a service (SaaS) applications with their data management systems. This is

Read More »

Apigee Scope Validation using OpenAPI Specification

In API security and management, we often use a lot of different security mechanisms to protect the requested resource behind the API Gateway. One of these mechanisms is the validation of scopes to authorize a client on a specific sub-resource of the API. Most of

Read More »