> For the complete documentation index, see [llms.txt](https://developers.tiqets.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developers.tiqets.dev/basics/caching.md).
# Caching
### Caching Product and Availability Information
We highly recommend that partners keep this information cached to avoid an excessive number of calls. When making a large number of calls, the partner is subject to being throttled for a period of time. Also, serving webpages using locally cached data will positively impact site speed and customer satisfaction.
#### Updating the cache
Perform the following calls in order to obtain the product, variant, and availability information.
| Data | Description | Example call |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------- |
| Product List | List of all visible products | GET /v2/products |
| Product Checkout Information | Information relevant to the product sale process. Includes data that must be shown to the customer, as well as the has\_timeslots and has\_dynamic\_pricing flags. | GET /v2/products/\/checkout\_information |
| Availability and Pricing | Dates, timeslots, variants and price information of a product. | GET /v2/products/\/availability |
#### How often should the cache be updated?
The update cycles mentioned in this document can be regarded as general recommendations. The actual update cycles that should be implemented depend on various factors such as the number of Tiqets products a partner offers to their customers, the average sales of a product within a certain timeframe, and the logic used by a partner to categorise products.
**Product information**
Product information rarely changes (variant prices change less than once a month). We recommend refreshing the following information once a week (for non-dynamic pricing products):
* Product List
* Product Checkout Information, for each product
Partners implementing product change notifications can update the cache only when receiving a change notification specific to a product.
**Image information**
Please note that due to the following reasons, you must update your image cache on a regular basis, at least once every 14 days:
* **Image credits can change**: We may need to update the credits of an image to ensure correct attribution. Check regularly that the image credits in your system are up to date and correspond with those returned by our API.
* **Images can be unpublished**: The content of an image may become outdated (e.g., if the product or venue has changed and the image no longer represents the current situation) or the image rights may change, meaning Tiqets is no longer permitted to share the image via the API. Check regularly that all images published in your system are still returned by our API.
**PLEASE UPDATE YOUR CACHE AT LEAST ONCE EVERY 14 DAYS**
Tiqets cannot be held liable for any infringement of copyrights or claims regarding outdated information.
**Variant information**
Variant information is returned by two endpoints:
* [**Availability**](https://portals.tiqets.com/distributorapi/docs#tag/Availability-and-Pricing-API/paths/~1products~1%7BproductId%7D~1availability/get): Returns availability for the defined time range and variant details of all variants that have availability in that time range.
* [**Product-Variants**](https://portals.tiqets.com/distributorapi/docs#tag/Availability-and-Pricing-API/): Returns all active variants for the given product. This endpoint can be used for mapping purposes and is not necessary if the partner relies solely on the variant information returned by the Availability endpoint.
**Availability**
The ideal way of caching availability information highly depends on the user interface and logic of each individual partner. Generally speaking, it is up to each partner to cache availability in a way that suits them and does not cause unnecessary load on the Tiqets API.\
\
Please note that availability for the current date and the next few days is usually more volatile and more likely to sell out than dates weeks or months into the future.
We recommend checking availability for the next two weeks several times a day. For dates more than one month in the future, checking once or twice a day should be sufficient in most cases.\
\
Depending on the individual cache refresh logic, it may make sense to check the [Availability](/basics/openapi/availability-and-pricing-api.md) endpoint before creating an order. This helps confirm availability and price for the order that is about to be made and helps prevent failed orders.
In order to make sure you remain up-to-date, it is recommended to check availability once again after an order is confirmed.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://developers.tiqets.dev/basics/caching.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.