# Screenshot caching and fresh captures

Understand ScreenshotEngine cache behavior, X-Cache response headers, successful-request usage, and the POST no-cache option for fresh screenshots.

Source: https://www.screenshotengine.com/docs/caching

## How screenshot caching works

By default, production requests can reuse a capture with matching options from the API’s in-memory cache. Cache entries have a 24-hour lifetime, but can disappear earlier when an instance restarts. Cache availability can differ between instances; it is not persistent file storage.

Changing capture options creates a different cache key. GET and POST requests are not guaranteed to share a cache entry. Save returned files in your own storage if you need permanent access.

## How do I force a fresh screenshot?

Send a POST request with cachePolicy: "no-cache". This bypasses both cache lookup and cache storage, so it does not replace an existing cached screenshot. GET has no cachePolicy parameter.

```bash
curl --fail-with-body --request POST 'https://api.screenshotengine.com/v1/screenshot' \
  --header "Authorization: Bearer $SCREENSHOTENGINE_API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{
  "url": "https://example.com",
  "format": "png",
  "cachePolicy": "no-cache"
}' \
  --output fresh.png
```

## Read the X-Cache response header

Inspect response headers to see whether a capture was reused. In cURL, add --dump-header headers.txt to save headers separately from the binary body.

| X-Cache | Meaning |
| --- | --- |
| HIT | The response was served from the capture cache. |
| MISS | The response was generated without a cache hit. |
| BYPASS | A POST request used cachePolicy: no-cache. |

## Do cached requests count toward usage?

Successful screenshot requests count toward monthly usage, including cache hits. Failed requests do not count as successful captures. Request rate limits still apply. Cache your own returned files if you need to serve the same image repeatedly without new API calls.