Browser-rendered pages

• If the capture had started and the budget runs out, you get 504 FetchCaptureTimeout. The TypeScript SDK doesn't retry it, so an outage on our side isn't amplified. A manual retry can still help. The timeout doesn't prove the page was at fault.
• If the request was still waiting for a browser, you get 529 FetchCapacityTimeout with Retry-After: 5. It's a capacity problem, not a page problem. The TypeScript SDK retries it.
• Expand takes up to 5 seconds to decide which, so the error arrives by 155 seconds. A result that lands in that window is still returned.
• Set your client timeout to 180 seconds. That leaves 25 seconds for the error to reach you. The TypeScript SDK's timeoutMs defaults to 60 seconds and cuts off long captures, so raise it. See TypeScript SDK.
• In a Batched Fetch, each item gets its own 150 seconds once it's scheduled, with the same two errors. Preparing the run doesn't count against it, since you poll for results instead of holding one request open.
• Fetches from the Playground follow the same budget and rules. Streamed requests report the outcome in the event stream.

Scrolling

scrollFullPage is the one public browser behavior control. It defaults to false. When true, Fetch attempts to scroll the page before capture to trigger lazy-loaded content, then returns to the top before capturing.

Use scrollFullPage when important content appears only after scrolling.

Screenshots

Fetch can take a full-page or viewport screenshot of any page it opens in a browser. To get one, set include.screenshot in the request body, not browserConfig. It comes back in the JSON object as data.screenshot, with its url and a fullPage flag. Anyone with the url can open the image, and it expires 15 minutes after the response; fetch again for a fresh one. Markdown Mode can't include the screenshot, but it's still saved with the Snapshot. JSON Mode returns a link to it. See Two modes.

The full schema is in the API reference. Everything else you can include, and how each mode returns it, is on Fetching a URL.

Redirects

Fetch follows redirects and captures the page it lands on. Each mode tells you where it landed in its own way:

Blocked pages

Fetch uses a real browser, so it reads many sites that block plain HTTP requests. When a site puts a bot check or CAPTCHA in front of a public page, Fetch gets past common ones automatically, such as "Just a moment..." checks, Cloudflare challenges and Turnstile, reCAPTCHA, and checkbox challenges. Fetch, Batched Fetch, and Crawl all do this, and you're charged once for the page.

Fetch reads public pages only. It doesn't sign in, pass paywalls, or open content behind other access controls. Some sites still refuse it, and those requests end as FetchBlocked.

• A blocked page returns 403 FetchBlocked. Its blockedType says why: captcha, botProtection, ipBlock, or authWall. You are not charged for blocked requests.

  {
    "_tag": "FetchBlocked",
    "url": "https://example.com",
    "blockedType"
  

A capture that was cut short can still return content. In the JSON object, meta.blocked or meta.loadingStatus marks it as partial. In a Batched Fetch, each item reports its own blocked state.

What you can and can't configure

You can set three browser options. Fetch manages everything else.

These are managed by Fetch and aren't options today:

If any of these become public, this page and the API reference change together.

Debug with replay

When output looks incomplete or surprising, open the replay. It shows what Fetch saw at capture time.

• Check for missing or lazy-loaded content.
• Inspect citations and evidence.
• Tell page behavior (what the site rendered) apart from extraction behavior (what Fetch kept).

Look for content that loaded late, a capture that was cut short, or an unexpected redirect. Playground & replay covers the full workflow.

Next steps

• Fetching a URL: control which artifacts Fetch returns.
• Playground & replay: inspect evidence visually.
• How Fetch works: the capture mental model.