Browser-rendered pages

What to expect:

• Pages are rendered before extraction, not captured as raw source.
• A page that never settles may be captured partially.
• Captures that fail or are refused surface as errors or blocked outcomes.
• When output looks off, replay shows what Fetch actually saw.

Every Fetch that waits for its result has one 150-second budget. It starts when the request is accepted and covers everything after that: queueing, loading, settling, scrolling, the Snapshot, and delivery. Retries inside Expand don't reset it.

• 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. 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 gets through many sites that block plain HTTP requests. Fetch does not guarantee to get past every CAPTCHA, login wall, or bot check.

• 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.