# Guidance for Caching Response Data
source: https://developer.mastercard.com/consumer-clarity/documentation/tutorials-and-guides/how-to-use-response-data/caching-response-data/index.md

This article provides guidance for caching the response data you receive from Consumer Clarity API calls and highlights important information about what data you can and can't cache.

## Overview {#overview}

Caching is the temporary, short-term storage of response information that you receive on the API. We allow some level of caching when the API call is initiated by some cardholder activity.

However, there are certain restrictions that apply to caching that must be followed, depending on the type of data received. The details below help guide you in deciding whether you can cache certain response data.
Note: Pre-loading data in bulk and storing the data ahead of time is not within the scope of caching.

### Guidelines for caching different types of response data {#guidelines-for-caching-different-types-of-response-data}

This section discusses types of data and the rules for caching each type:
![Caching merchant details](https://static.developer.mastercard.com/content/consumer-clarity/documentation/img/merchant.png)
![Caching merchant logos](https://static.developer.mastercard.com/content/consumer-clarity/documentation/img/logo.png)

#### Third-party data {#third-party-data}

###### Not allowed {#font-colorrednot-allowedfont}

* Issuers consent to receive regulated third-party data.
* Data is flagged as "third-party" in response.
* Caching of third-party data is **not allowed**.

#### Logo image {#logo-image}

###### Not allowed {#font-colorrednot-allowedfont}

* Logo images sourced directly from merchants; Merchant IP.
* Contract allows on the **display** of logo image.
* Storage of these images, either long-term or short-term, is **not allowed**.

#### Non-third-party data {#non-third-party-data}

###### Not recommended {#font-colororangenot-recommendedfont}

* Not recommended as data changes daily.
* Short-term caching that's initiated by cardholder activity is allowed for up to 24 hours.
* Calls to pre-load data without cardholder activity is **not allowed**.

#### Logo URL {#logo-url}

###### Not recommended {#font-colororangenot-recommendedfont}

* Logo URLs get renewed with logo updates.
* Caching of this data isn't recommended since it can result in broken links.
![Caching digital receipts](https://static.developer.mastercard.com/content/consumer-clarity/documentation/img/receipt.png)
![Caching carbon scores](https://static.developer.mastercard.com/content/consumer-clarity/documentation/img/carbon-calc.png)

#### Digital receipt data {#digital-receipt-data}

###### Not allowed {#font-colorrednot-allowedfont}

* Digital receipt data is proprietary to the merchant.
* Storage of digital receipt data is **not allowed**.

#### Carbon score {#carbon-score}

###### Not recommended {#font-colororangenot-recommendedfont}

* Carbon scores take into account the currency conversion rates.
* Caching of this data isn't recommended since conversion rates are fluid and subject to change.

#### Digital receipt URL {#digital-receipt-url}

###### Not allowed {#font-colorrednot-allowedfont}

* A digital receipt URL has a timeout of 15 minutes from the moment it's generated. This is for security purposes.
* Caching of the digital receipt URL is **not allowed**.

For more guidelines around caching non-third-party information, review the section on [using the dataPolicyConsent response data](https://developer.mastercard.com/consumer-clarity/documentation/tutorials-and-guides/how-to-use-response-data/displaying-merchant-details/index.md#use-the-datapolicyconsent-response-data).

### Preload and prefetch requests {#preload-and-prefetch-requests}

Always try to follow the guidelines outlined in this article for caching response data information. However, you might sometimes have a need to cache information for performance reasons and to enhance the cardholder experience.

[Tips for Sending Requests](https://developer.mastercard.com/consumer-clarity/documentation/tutorials-and-guides/tips-for-sending-requests/index.md#preload-requests) offers suggestions for how you can best manage your *request* volumes by preloading and prefetching your requests. In this way, you can avoid any complications that might arise due to caching the response data.

## Next Steps {#next-steps}

* Learn about the differences between [List View vs. Detail View](https://developer.mastercard.com/consumer-clarity/documentation/tutorials-and-guides/how-to-use-response-data/list-view-detail-view/index.md).
* [Display Merchant Details](https://developer.mastercard.com/consumer-clarity/documentation/tutorials-and-guides/how-to-use-response-data/displaying-merchant-details/index.md) suggests different ways you can use the merchant detail response data in your banking app.
* [Display Transaction Details](https://developer.mastercard.com/consumer-clarity/documentation/tutorials-and-guides/how-to-use-response-data/displaying-transaction-details/index.md) offers tips for how to display transaction detail response data in your banking app.
* [Display Smart Subscriptions](https://developer.mastercard.com/consumer-clarity/documentation/tutorials-and-guides/how-to-use-response-data/displaying-subscription-controls/index.md) offers tips for how to display smart subscriptions response data in your banking app.
* Review [Tips for Sending Requests](https://developer.mastercard.com/consumer-clarity/documentation/tutorials-and-guides/tips-for-sending-requests/index.md) for suggestions to consider when sending your requests.