Straight answers about capturing, waiting for dynamic pages, PDFs, AI extraction, and quotas.
Send a GET request to /v1/screenshot with a url parameter and your API key. The response streams back the image bytes directly — no polling, no job queue, no SDK required. GET /v1/screenshot reference →
No. That's the whole point of a rendering API — you send a URL and get bytes back, and we run and patch the browsers, handle concurrency, and absorb the memory and cold-start problems that come with running Chrome yourself.
Set full_page=true, and pair it with wait_until=networkidle, a wait_for selector, or a fixed delay so lazy-loaded images and sections have actually loaded before the capture happens. Full-page screenshots of lazy-loaded pages →
Yes — pass a CSS selector as the selector parameter and the capture is cropped to that element instead of the viewport or full page. GET /v1/screenshot reference →
Not today — the API doesn't accept cookies, auth headers, or a login step to inject into the render, so it can only capture publicly reachable pages.
Yes — set format=pdf on /v1/screenshot and you get a PDF of the rendered page instead of an image, from the exact same request shape. GET /v1/screenshot reference →
Use wait_until to pick when navigation is considered done (load, domcontentloaded, or networkidle), wait_for to block on a specific CSS selector appearing, and delay for a fixed extra pause. Most pages need a combination of the three. wait_until vs wait_for vs delay →
Yes — GET /v1/extract takes a url and a prompt or a JSON schema, and returns structured JSON extracted from the page with AI. Available on the Starter and Growth plans. AI data extraction →
Each screenshot or PDF call counts as one render; AI extraction counts against a separate quota. Free plans are capped at their quota. Paid plans can burst up to 3x their included quota as billed overage before requests are rejected until the next billing period. Rate limits & quotas →
Generally yes for publicly accessible pages, in the same way viewing a page in a browser is legal — but how you store, display, or redistribute the resulting image can still be governed by copyright, a site's terms of service, or trademark law. This isn't legal advice; check with a lawyer if you're building something that republishes captured content at scale.