Prerender-compatible API

The render API answers in the same format as Prerender's service, so existing Prerender middlewares can use it by changing the service address and token. You can also call it from your own code.

Render a page

GET https://render.intercrawl.com/https://example.com/pricing
X-Prerender-Token: ic_live_...
User-Agent: <the crawler's user agent, as received>
X-Intercrawl-Client-IP: <the crawler's IP address, as your platform reports it>

• The path is the full URL of the page, on one of your account's verified sites. www. and the bare domain are the same site.
• The token goes in X-Prerender-Token (or X-Intercrawl-Token).
• Send the crawler's own user agent: Intercrawl decides from it whether the request is a crawler, and which render (phone or computer) to use.
• Send the client IP from a source your platform guarantees (such as Cloudflare's CF-Connecting-IP), never from X-Forwarded-For as the client sent it. Without an address, crawlers are treated as unverified and still rendered.

The answer is the page: the status code, a Location header for redirects, and the HTML. A browser's request, or a crawler whose address is not its operator's, gets your own page from your server. See How serving works and Response headers.

Render pages again

POST https://render.intercrawl.com/recache
Content-Type: application/json
X-Prerender-Token: ic_live_...

{ "urls": ["https://example.com/pricing", "https://example.com/blog/launch"] }

Up to 1,000 URLs per request (or "url" for one). Each URL on your sites is queued to be rendered again; others are counted as rejected and never fetched. Prerender's body format with prerenderToken in the JSON also works.

Your middleware's rules

• Ask the render API only for GET and HEAD requests from crawlers, never for visitors, and never for requests that already carry X-Prerender: 1 (Intercrawl's own renderer sends it).
• Give it at most 10 seconds. On a timeout or an error, serve your own page.