Sign in

Guide

Screenshot a page behind a login

Send the session with the request. The browser arrives already authenticated, so the capture is the page your user sees, not the login form.

Most pages worth capturing are behind something: a dashboard behind a session cookie, an internal tool behind a bearer token, a staging site behind basic auth. A render API that cannot carry credentials can only ever photograph your login form.

Renderwolf takes headers, cookies and an authorization value on every render, and applies all of them before navigation. That ordering is the part that matters: a cookie that arrives after the page has loaded has missed the request it was meant to authenticate.

With a session cookie

The common case for anything a person logs into. Take the session cookie your app already issues and attach it to the render. domain is required, not optional: Chromium silently drops a domainless cookie set before navigation, and the render would come back quietly logged out - so the API refuses the request instead, as a 400 naming the cookie.

curl -X POST https://api.ironfang.uk/renderwolf/v1/screenshot \
  -H "Authorization: Bearer if_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://app.example.com/dashboard",
    "cookies": [
      { "name": "session", "value": "YOUR_SESSION_TOKEN", "domain": "app.example.com" }
    ]
  }' \
  --output dashboard.png

With a bearer token or basic auth

For APIs, staging environments and anything that reads the Authorization header, the shorthand spells it once. It sets the Authorization header on requests for the page.

curl -X POST https://api.ironfang.uk/renderwolf/v1/screenshot \
  -H "Authorization: Bearer if_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://staging.example.com/report",
    "authorization": "Bearer YOUR_APP_TOKEN"
  }' \
  --output report.png

Custom headers and user agent

Anything else the page needs - an API key header, a tenant selector, a feature flag - goes in headers, sent with every request for the page. user_agent overrides the browser identity, including the one a device preset would set.

{
  "url": "https://app.example.com/admin",
  "headers": { "X-Tenant": "acme", "X-Feature-Preview": "on" },
  "user_agent": "StatusBot/1.0 (+https://example.com/bot)"
}

What this cannot do, on purpose

Private-network targets stay blocked whatever credentials you attach. The SSRF guard runs before any of this, so a session cookie cannot be pointed at something internal to our network or yours. And Renderwolf never fills in login forms - you hand it a session that already exists, which is both simpler and does not put a password in a render request.

Next