Crawler / Page / Render

Extract JavaScript-rendered pages as Markdown.

Send a public URL with method=render when useful content appears after JavaScript runs. AnyCrawler opens it in a browser, waits for the selected browser_wait_until load condition, and returns Markdown from the loaded DOM. This wait does not guarantee all delayed business data is present. With accept_cache=true, a matching render result may be reused. The base request costs 10 credits; metadata, links, or media each add 1 credit.

Start Free Read Docs

Browser path

Crawl content that only appears after JavaScript runs

Render is for pages where the useful body is missing from the initial HTML: single-page apps, pricing tables loaded after hydration, and client-side documentation. The browser waits for navigation readiness before extracting the loaded DOM; later API responses or content that requires interaction can still be absent.

When the target page is unknown, usepage search first. When the rendered state needs review or audit evidence, add ascreenshot for the same URL.

JavaScript executionClient-rendered DOMBrowser wait controlsMarkdown normalized

curl -X POST "https://api.anycrawler.com/v1/crawl/page" \
  -H "Authorization: Bearer $ANYCRAWLER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/app/pricing",
    "method": "render",
    "browser_wait_until": "networkidle2",
    "accept_cache": true,
    "include_metadata": true,
    "include_links": true,
    "markdown_variant": "readability"
  }'

This example requests metadata and links, so a fresh response uses 12 credits: 10 base + 1 for each optional group.

How it works

Open, wait, extract rendered content

The gateway handles request validation, account checks, cache lookup, browser routing, response filtering, and credit settlement.

Submit the target URL

Send a POST request with url and method=render. Optional flags control browser wait, metadata, links, media, Markdown variant, and cache reads.

AnyCrawler opens a browser path

The gateway validates your API key, checks credits and browser concurrency, applies cache policy, and routes the page through the render worker.

JavaScript output becomes Markdown

Client-loaded content is extracted from the rendered DOM and normalized into Markdown, token counts, metadata, and links when requested.

You get usage evidence

The response includes status, final URL, credits_used, cache_timestamp, and request headers for production debugging.

Use cases

Where render beats a plain HTML fetch

Use the render page API when the answer is not in the initial response and the browser state changes what your agent can trust.

Use

JavaScript pricing pages

Capture pricing tables, plan cards, and comparison blocks that appear only after a framework hydrates the page.

Use

Client-side documentation portals

Render docs sites that depend on client routing, search indexes, or JavaScript-generated navigation before extracting Markdown.

Use

Review rendered page state

Read the loaded page's Markdown and source URL before quoting terms or routing a finding for human review.

{
  "ok": true,
  "requested_url": "https://example.com/app/pricing",
  "canonical_url": "https://example.com/pricing",
  "final_url": "https://example.com/app/pricing",
  "status_code": 200,
  "cache_timestamp": 0,
  "credits_used": 12,
  "results": {
    "title": "Example Pricing",
    "description": "Plans loaded by a JavaScript app",
    "markdown": "# Example Pricing\n\nFree plan\nBuilder plan\nGrowth plan...",
    "markdown_tokens": 736,
    "metadata": {
      "description": "Plans loaded by a JavaScript app"
    },
    "links": [
      {
        "text": "Compare plans",
        "href": "https://example.com/pricing/compare"
      }
    ]
  }
}

cache_timestamp=0 marks this fresh response; a reused render result carries a cache marker. Optional field groups each add 1 credit.

What you get

Rendered DOM in a smaller agent-ready shape

The render response is built for JavaScript-heavy sites. Use Markdown for model context, URLs for provenance, status fields for debugging, and optional extraction fields when the rendered page should seed deeper crawl workflows.

JavaScript-loaded page content converted to Markdown
Final URL and status code for traceability
Optional metadata, links, and media from the rendered page
Credit, cache, and request fields for cost control

Request fields

Use browser controls only when the page needs them

The stable public contract focuses on the fields below. Undocumented passthrough fields are not part of new integrations.

Field	Type	Required	Notes
`url`	string	Yes	The public page URL to open in the browser render path.
`method`	"render"	No	Selects the browser path for JavaScript-loaded and client-rendered pages. This is the default method.
`browser_wait_until`	"domcontentloaded", "load", "networkidle0", "networkidle2", or null	No	Waits for the selected browser load condition before extraction. This does not guarantee every late-loaded item has appeared.
`accept_cache`	boolean	No	Defaults to false. When true, a matching valid render result may be reused; check cache_timestamp in the response.
`include_metadata`	boolean	No	Adds results.metadata when available. Defaults to false; +1 credit.
`include_links`	boolean	No	Adds results.links when available. Defaults to false; +1 credit.
`include_media`	boolean	No	Adds results.media when available. Defaults to false; +1 credit.
`markdown_variant`	"markdown" or "readability"	No	Defaults to markdown for fuller output. Readability may omit some page information; both return results.markdown at no extra cost.
`user_agent`	string or null	No	Optional paid-plan override for the outbound user agent. Empty strings and null are treated as unset.

Response fields

Fields your integration can rely on

AnyCrawler strips internal timing and debug fields before returning the public response.

Field	Meaning
`ok`	Whether the gateway completed the crawl successfully.
`requested_url`	The URL submitted in the request.
`canonical_url`	Canonical URL discovered from the rendered page when present.
`final_url`	The final URL after redirects and browser navigation.
`status_code`	HTTP status code from the target page when available.
`cache_timestamp`	Cache marker for reused responses. Zero means a fresh upstream result.
`credits_used`	Credits settled for the request.
`results.title / description / keywords`	Extracted page identity and descriptive fields when available.
`results.markdown`	Clean Markdown body extracted after browser rendering.
`results.markdown_tokens`	Estimated token count for the Markdown payload.
`results.metadata`	Optional rendered page metadata when include_metadata is true.
`results.links`	Optional links visible after render when include_links is true.
`results.media`	Optional extracted media when include_media is true.
`error_code / error_message / retryable`	Failure details returned when ok is false; retryable indicates whether retrying can help.

const response = await fetch("https://api.anycrawler.com/v1/crawl/page", {
  method: "POST",
  headers: {
    authorization: `Bearer ${process.env.ANYCRAWLER_API_KEY}`,
    "content-type": "application/json",
  },
  body: JSON.stringify({
    url: "https://example.com/app/pricing",
    method: "render",
    browser_wait_until: "networkidle2",
    accept_cache: true,
    include_metadata: true,
  }),
});

const data = await response.json();

console.log(data.results?.markdown);
console.log(response.headers.get("x-request-id"));

Use the same stable public request fields from any runtime with standard HTTP support.

Render vs fetch

Use render for JavaScript. Use fetch for cheap speed.

Render is the browser path for pages that need JavaScript, client-side routing, or dynamic UI content before extraction. If the target page already exposes useful HTML, switch the same endpoint to method=fetch for a faster 2-credit request.

Mode	Best for	Base cost
`render`	JavaScript apps, client-side routing, browser-dependent pages	10 credits
`fetch`	Docs, articles, reference pages, and other pages with useful HTML	2 credits
`cache hit`	Render only: a matching valid result when accept_cache=true	1 credit

Errors

Status codes are explicit enough for production handling

Use response status plus error_code and request headers to route retries, credit issues, authentication problems, and browser concurrency limits.

200Page rendered and normalized.

400Invalid JSON or unsupported request field value.

401Missing, invalid, or revoked API key.

402Account does not have enough credits.

403Account inactive or paid-plan-only field requested.

409Gateway could not reserve account capacity; retry the request.

413Request body exceeds the 256 KiB public gateway limit.

429Rate limit or browser concurrency limit reached.

502Upstream browser connection failed.

503Database or upstream worker is not configured.

504Target page or browser worker timed out.

Headers

Track every render request

Successful and error responses include gateway metadata headers such as x-request-id, x-credits-reserved, and x-credits-used. Store them when you need support or cost audits.

Pricing

Render credit and browser limits

A fresh render uses 10 credits; a matching render cache hit uses 1 base credit when accept_cache=true. include_metadata, include_links, and include_media each add 1 credit; readability adds none. Browser concurrency limits simultaneous render jobs and is separate from requests per minute.

The default accept_cache value is false. Compare included credits, request rates, and browser slots on the full pricing page.

FAQ

Common render API questions

Short answers for teams deciding when JavaScript rendering is worth the browser path.

When should I use render instead of fetch?

Use render when the useful content appears only after JavaScript runs. Use fetch when it is already in the returned HTML; fetch does not use the render cache.

Does render wait for JavaScript-loaded content?

Render waits for the selected browser_wait_until condition, such as load or networkidle2, then extracts the DOM. A load condition cannot guarantee that every delayed API response or business record has appeared.

Can render click buttons, sign in, or scroll indefinitely?

The public page crawl request opens one URL and extracts the loaded page. It does not expose arbitrary click, login, or infinite-scroll steps. Check the returned Markdown before relying on it as complete evidence.

Why does render cost more than fetch?

Render uses browser execution and plan-specific browser concurrency, which is heavier than a lightweight HTTP fetch. Use it for JavaScript pages, and use fetch for cheaper, faster HTML-first pages.