Snap — Screenshot API

If a URL redirects to a login wall, Snap follows the redirect and captures the final rendered page (usually the login UI). That comes back as a normal screenshot and uses a credit. We don’t classify “login wall” as a special failed capture, and we don’t try to bypass auth/paywalls. If the render itself fails, no credit is used. Failed-capture policy + free cache hits are intentional for cron/n8n predictability — happy to move that copy higher on the page.

Fair point. Today failed captures already do not burn a credit, but we do not yet rate-limit or hard-cap how many failed attempts a key can make in a window. A soft failed-scan cap (or clearer abuse guardrails) is a good safety valve for cron loops that keep retrying a bad URL — I'll put it on the list. If you try Snap and hit a failure pattern that would have burned money elsewhere, tell me what you saw: https://snap.flyhold.in/docs.html

Good question. Snap is not meant to bypass CAPTCHA or bot challenges (we say so in the docs). If Chromium lands on a challenge page that still returns HTTP 200, you get a screenshot of that challenge UI and it counts as a successful capture (uses a credit). We don’t currently emit a distinct error code for “looks like a bot check.” True failed captures (couldn’t complete the render) do not burn a credit. For n8n today: treat surprise challenge images as a workflow concern (e.g. visual/OCR check → manual review). Distinct challenge detection + a clear error code is a fair ask — on the list. Docs: https://snap.flyhold.in/docs.html · n8n recipe: https://snap.flyhold.in/guides-n8n.html

We do expose these already: - wait_until: load (default), domcontentloaded, networkidle0, networkidle2 - wait_for_selector: CSS selector before capture - delay: extra ms after navigation - full_page=true + optional scroll_to_load=true for lazy content Example: curl -G "https://snap.flyhold.in/v1/take" \ --data-urlencode "api_key=YOUR_API_KEY" \ --data-urlencode "url=https://example.com" \ --data-urlencode "full_page=true" \ --data-urlencode "scroll_to_load=true" \ --data-urlencode "wait_until=networkidle2" \ --data-urlencode "file_type=png" \ -o full-page.png CamelCase aliases (waitUntil, waitForSelector) work too. Full param list: https://snap.flyhold.in/docs.html

Agree on both. There’s already a copy-paste HTTP Request recipe (no community node yet): https://snap.flyhold.in/guides-n8n.html — an importable n8n community node is on the wishlist. Cache behavior today: default ≤1 hour render cache; HIT does not burn a credit; response header X-Snap-Cache: HIT|MISS|BYPASS; cache=false forces a miss (billed as a normal capture). I’ll make the MISS case more explicit next to pricing — thanks for the nudge. Site: https://snap.flyhold.in · pricing: https://snap.flyhold.in/#pricing

For monitoring and visual regression, Chromium isn’t pinned to a fixed build per account today — updates can shift fonts/layout slightly between captures weeks apart. If you need hard determinism, keep a golden baseline and treat diffs with a tolerance, or only force cache=false when you intentionally want a fresh render. Pinning engine versions per key is a fair ask for that use case — on the list. Docs: https://snap.flyhold.in/docs.html