Screenshot caching

Ssnap can serve a previously rendered capture instead of launching the browser again. Caching is opt-in per request: without cache_ttl, every call renders fresh.

curl -G https://ssnap.cc/api/v1/screenshot \
  -H "Authorization: Bearer $SSNAP_API_KEY" \
  --data-urlencode "url=https://example.com" \
  --data-urlencode "cache_ttl=3600" \
  --data-urlencode "response=url"

cache_ttl is measured in seconds, from 0 (disabled) up to 2592000 (30 days).

What counts as identical

A capture is reusable when it belongs to your team, succeeded, was created within cache_ttl seconds, still has its stored file on disk, and matches the cache key:

sha256(url + device_id + output parameters)

The output parameters in that key are theme, format, quality, device_id, width, height, full_page, network_idle, delay, selector, background, border_width, border_color, watermark_text, watermark_size, watermark_color, watermark_x, watermark_y.

Delivery options (cache_ttl, response, callback_url) are not part of the key. Asking for response=url can therefore hit a capture originally taken as binary bytes.

Quota effect

Rate limiting is unaffected: cache hits still count against your per-minute allowance, because they still cost a request.

Detecting a hit

When a hit will not happen

• cache_ttl is 0 or absent.
• Any output-affecting parameter changed, including a delay or quality tweak.
• The earlier capture failed, or was captured by a different team.
• The stored file was pruned by retention, or is otherwise gone. A missing file is skipped rather than served, and a fresh render happens instead.

Practical pattern

Pick a TTL matching how fast the target page changes:

Next