ForHosting KIT · Web Scraping & Monitoring

Render a JavaScript page

Most scrapers fetch a URL and get a shell — a near-empty document waiting for a bundle to finish loading. This rendered HTML API runs that bundle first: a real browser executes the page's JavaScript, waits for it to settle, and hands back the DOM exactly as a visitor's browser would build it.

● StablePer request + per URL$0.040

Run — $0.040 + $0.001/URL How it works & API

Use it from WebAPIEmailApp soonTelegram soon

Run it online

Run this on our servers with your account. Free tools run in your browser; this one bills your KIT balance per the price above.

The gap between source and DOM

View-source and the rendered page have grown apart. Frameworks that build the interface client-side ship a document that's mostly script tags; the content a person actually reads only exists after that script runs. Anyone trying to scrape, index, test or archive such a page against the raw HTML response is working with a page that was never finished.

What actually happens on a request

A headless browser instance opens the URL, executes scripts, applies stylesheets, and waits through network idle or a condition you specify, then serializes the live document object model back into HTML. What you get is not the server's response — it's the page as it exists after the browser has done its job, including content injected by client-side frameworks, hydration, and deferred fetches.

Why this differs from a plain HTTP fetch

A basic HTTP request never runs a script; it just returns bytes. That's fine for a static blog and useless for a single-page application, a dashboard behind client-side routing, or any page that decides what to show based on cookies, viewport or an API call made after load. Rendering closes that gap without you standing up and maintaining a browser farm.

Where headless rendering came from

Headless browsers started as testing tools, built to drive real engines without a visible window so continuous integration could click through a UI unattended. Using that same machinery to capture a finished DOM for scraping and archiving is a natural extension — the browser was already doing the rendering work, it just needed an endpoint that asked for the result instead of a test outcome.

Fitting rendering into a pipeline

Rendered HTML becomes the input to whatever comes next: parse it, feed it into the article extractor, or diff it against yesterday's render to spot a layout change. Because the response is async with a task_id and a webhook, a rendering step slots into a queue-based pipeline the same way any other task does — no synchronous browser session to keep open on your end.

What you can do with it

Scraping single-page applications

Pull structured data out of a React or Vue dashboard that only populates its tables after an API call fires client-side.

SEO and rendering audits

Compare what search engines actually see against your intended markup by capturing the post-JavaScript DOM.

Feeding downstream extraction

Render a page first, then hand the result to the article extractor or the Markdown converter for content that never loads in raw HTML.

QA against production behavior

Verify a client-side redirect, a cookie banner, or an A/B test variant rendered the way it should before a release ships.

FAQ

How is this different from a screenshot?

A screenshot returns an image; this endpoint returns the rendered document as HTML text, so you can parse, diff or feed it to another tool.

Does it run JavaScript?

Yes — a real browser engine executes scripts, applies styles and waits for the page to settle before the DOM is captured.

Can I wait for a specific element before capturing?

Yes, you can target a selector or a load condition so slow-hydrating content is included rather than captured half-built.

Is there a free trial?

There's no free tier — free tiers get abused and slow everyone down. Access runs on a prepaid ForHosting KIT balance: top up from $10.00 (it never expires) and each request is charged at its published price, so a call with no balance returns HTTP 402. No subscription, no tokens, no invented credits, and a failed task is never charged.

How is it billed?

$0.040 per request plus $0.001 per URL, published on this page with no hidden per-second browser fees.

What if the page fails to render?

The task retries up to three times automatically; a run that still fails returns a clear error and is never charged.

Can I render pages that require login?

You can pass cookies or headers needed to reach the authenticated view, as long as you're authorized to access that page.

How do I get the result?

By signed webhook once rendering finishes, or a signed link valid for 24 hours if you'd rather fetch it yourself.

For developers — API access

Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.

API endpoint

POSThttps://api.kit.forhosting.com/web/render

Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, and soon from our app, email and Telegram.

Call it from your stack

curl -X POST https://api.kit.forhosting.com/web/render \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d &#39;{"url":"https://ejemplo.com"}'

const res = await fetch("https://api.kit.forhosting.com/web/render", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "url": "https://ejemplo.com"
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/web/render",
    headers={"Authorization": f"Bearer {os.environ[&#39;KIT_KEY']}"},
    json={
    "url": "https://ejemplo.com"
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/web/render", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => &#39;{"url":"https://ejemplo.com"}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"url":"https://ejemplo.com"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/web/render", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Example request

{
  "url": "https://ejemplo.com"
}

Example response

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "web.render",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.

Pricing

Per request$0.040

Per URL$0.001

Published price — no tokens, no invented credits. A failed task is never charged.

Limits

`timeout_sec`	30
`max_crawl_pages`	25

Errors

HTTP	Code	Meaning
`401`	`unauthorized`	Missing or invalid API key.
`402`	`insufficient_balance`	Your balance doesn't cover the task price.
`404`	`unknown_type`	That task type doesn't exist.
`429`	`rate_limited`	Too many requests. Use the webhook instead of polling.
`422`	`task_failed`	The task failed after 3 retries. You are never charged for it.

Read the full KIT documentation →