Snap — Screenshot API

I think having a cap on failed scans would also be helpful

I will try it it can be helpful. I have made a puzzle game which is wordable give it a try https://wordable.live/

For automated website previews, a bot-check page can return HTTP 200 and still produce an unusable screenshot. Does Snap detect challenge pages and count those as failed captures too? A distinct error code would make it easier to send those cases to manual review in n8n.

The failed-capture credit policy and free cache hits make this unusually predictable for scheduled jobs. For SPA screenshots, do you expose wait-until or selector options for fonts and lazy-loaded content? A small example for full-page capture would be useful for visual regression workflows.

The pricing shape is honest — 200/month with no card, and not billing cache hits, is exactly what cron jobs and n8n workflows need instead of a free tier that dies quietly. Two suggestions: since you call out n8n, shipping an importable community node (or a copy-paste HTTP node recipe in the docs) would remove most of the setup friction for that audience. Second, documenting the cache-miss case explicitly would help people tune TTLs when a workflow runs on a tight schedule.

Prefect! will use it for generating OG images

Nice — OG images are a solid fit for Snap. Typical pattern: render a public template URL (or a page you control) via GET /v1/take with file_type=png or webp, then use that image URL in your meta tags / social share step. Cookie banners are blocked by default so the image stays clean. 200 free/mo to try: https://snap.flyhold.in · docs: https://snap.flyhold.in/docs.html — if a specific template URL looks wrong, tell me and I’ll help debug.

For monitoring and visual-regression use cases - diffing a page's screenshot over time to catch unexpected changes - is the rendering engine version pinned per account, or could two calls a month apart differ just from a browser or font update on your end? That determinism matters more than raw speed for that use case, same spirit as the failed-capture policy - predictability is the actual feature for anything running on a schedule.

The two details that would decide this for me sit near the bottom: failed captures not burning a credit, and cache hits inside an hour being free. Those are what make a nightly cron predictable to budget. Worth moving up next to the pricing table. One question: what does it return for a URL that redirects to a login wall?