Spice.ai caches HTTP API responses at two layers: a connector-level HTTP response cache that respects upstream Cache-Control headers, and dataset-level acceleration with refresh_mode: caching that stores API responses in a local accelerator with configurable TTL and stale-while-revalidate semantics.
This pattern is useful for applications that query external REST APIs repeatedly — for example, caching search results from a third-party API so that the same query served to multiple users does not trigger redundant upstream requests.
Cache-Control: max-age headers. Dataset-level caching adds TTL, stale-while-revalidate, and stale-if-error on top, providing application-controlled cache behavior independent of upstream headers.allowed_request_paths, request_query_filters, and request_body_filters, preventing unbounded cache growth.Cache JSON responses from a REST API with stale-while-revalidate:
Query the cached API data over SQL:
The first query triggers a fetch from the upstream API. Subsequent queries within 30 seconds are served from the local accelerator. After 30 seconds, the cached result is served immediately while Spice revalidates in the background. If the upstream API is unavailable, the stale cached result is served instead of an error.
Limit which API paths and parameters are cached to prevent unbounded cache growth:
Only requests matching the allowed paths with query and body sizes within the configured limits are cached.
The SQL results cache adds a third caching layer for HTTP API data. While the HTTP connector caches raw responses and refresh_mode: caching stores parsed data in the accelerator, the SQL results cache stores the output of executed SQL queries in memory so that identical queries return instantly without re-querying the accelerator.
In this three-layer configuration:
Cache-Control headers.Identical SQL queries within 10 seconds are served from memory. After 10 seconds, the query re-executes against the accelerator (which may still be serving from its dataset-level cache).
The Results-Cache-Status response header indicates cache state: HIT, MISS, BYPASS, or STALE. Clients can bypass the results cache using the Cache-Control: no-cache header.
:::warning
Do not configure stale_while_revalidate_ttl on both the SQL results cache (runtime.caching.sql_results) and the dataset caching accelerator (acceleration.params.caching_stale_while_revalidate_ttl) for the same dataset. Use one or the other to avoid conflicting revalidation behavior.
:::