Log in Request access →
HEADLESS BROWSER • Persistent Stealth Contexts

Open a browser. Keep the session.

Spin up a persistent stealth browser, render JavaScript, drive it with a JSON action script, and carry cookies and storage across every call. The rendering and session primitive — not a server farm you have to run.

Request access → Read the docs →

Need an agent that decides its own steps? See browser automation. Just need one page fetched? Use the scraping API.

CORE CAPABILITIES

The headless browser primitive, without the server fleet.

STATEFUL

Sessions that keep state

Open a session once and every render and script call after it reuses the same cookies, localStorage, and authenticated context. Log in on the first call, keep working across the rest — no re-authenticating per request, no juggling cookie jars yourself.

STEALTH BYPASS

Managed stealth engine

Every session runs on our managed stealth browser engine — fingerprint-randomized, headless flags stripped, hardened against the JavaScript checks that flag ordinary headless Chrome. The same protections that power our scraping stack apply to your live sessions.

FIDELITY

Render JavaScript, get clean HTML

Point a session at a URL and it executes the page's JavaScript, waits for network idle or DOM stability, and returns rendered HTML or text. The response is canonical across tiers — same fields whether the page was simple or fought back.

ZERO OPS

No browser farm to run

No idle Chromium pool, no autoscaling to tune, no out-of-memory crashes at 3 a.m. Open a session, do the work, close it. Opening is free; you are billed per render and per script call like the rest of the API.

SESSION LIFECYCLE

The session lifecycle, end to end.

Open, render, script, close — four calls, one bearer token, state preserved throughout.

Open a session 
# Open a persistent stealth browser session. Free — you pay on render/script.
curl -X POST https://api.ollagraph.com/v1/session \
  -H "Authorization: Bearer $OLLAGRAPH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"stealth": true}'
# => { "session_id": "sess_8f3a...", "engine": "...", "expires_at": "..." }
Render JavaScript 
# Render a URL inside that session — JavaScript executes, cookies & storage persist.
curl -X POST https://api.ollagraph.com/v1/session/sess_8f3a.../render \
  -H "Authorization: Bearer $OLLAGRAPH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/dashboard",
    "wait_until": "networkidle",
    "format": "html"
  }'
# Returns rendered HTML/text plus tier_used and final_url. State carries to the next call.
Run an action script 
# Run a JSON action script in the same session — click, type, wait, screenshot.
curl -X POST https://api.ollagraph.com/v1/session/sess_8f3a.../script \
  -H "Authorization: Bearer $OLLAGRAPH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "actions": [
      {"type": "click", "selector": "#load-report"},
      {"type": "wait", "ms": 1500},
      {"type": "screenshot", "full_page": true}
    ]
  }'
Inspect & close 
# Check a session's state, then close it to free the browser context.
curl https://api.ollagraph.com/v1/session/sess_8f3a... \
  -H "Authorization: Bearer $OLLAGRAPH_API_KEY"
# => { "engine": "...", "age": 42, "idle_seconds": 9, "last_url": "https://..." }

curl -X DELETE https://api.ollagraph.com/v1/session/sess_8f3a... \
  -H "Authorization: Bearer $OLLAGRAPH_API_KEY"

Part of the full 124-endpoint surface. For one-shot fetches see scraping, for whole-site sweeps see crawling, and for agent-driven flows see automation.

FREQUENTLY ASKED QUESTIONS

Headless browser questions

1

How is the session surface different from the scraping API?

The scraping API is one-shot: send a URL, get cleaned data back in a single call. The session surface is stateful — you open a browser, then make many render and script calls that share cookies, storage, and the authenticated context. Reach for the scraping API when one request is enough; reach for a session when you need a page to remember what happened on the call before.
2

How is the session surface different from browser automation?

Browser automation describes a goal in natural language or a high-level macro and lets an agent decide the steps. The session surface is the lower-level primitive: you open the browser, drive it with explicit render and script calls, and control the lifecycle yourself. Automation is built on top of this rendering and session foundation.
3

What endpoints make up the session lifecycle?

Four. POST /v1/session opens a persistent browser session and is free. POST /v1/session/{session_id}/render loads a URL inside it, executing JavaScript and keeping cookies and storage. POST /v1/session/{session_id}/script runs a JSON action script — click, type, wait, scroll, screenshot. DELETE /v1/session/{session_id} closes it and frees the browser context. A GET on the same path inspects engine, age, idle time, and the last URL.
4

How is a session billed?

Opening a session is free. Billing happens on the work: each render and each script call is metered like any other endpoint. Failed calls are auto-refunded, so a render that times out never costs you a credit. Pricing follows the standard credit model — see the pricing page for current packs.
5

How do sessions stay isolated?

Each session gets its own fresh browser context with no shared state from any other customer or session. Cookies, storage, and cache live only inside that session and are destroyed when you close it or it idles out. Nothing scraped is persisted on our side beyond the response we hand back.
6

What can I do in a script call?

Drive the page with a JSON array of actions — click a selector, type into a field, wait a fixed time or for an element, scroll, submit a form, and capture a screenshot. The same action vocabulary works on every site, so there is no per-target Playwright or Puppeteer code to maintain. Generic libraries like Playwright and Puppeteer remain familiar reference points, but you describe the steps as data, not code.
7

What about pages behind a login?

This is the headline case for sessions. Use a script call to drive the login form on the first request, then every subsequent render and script call in that session reuses the authenticated cookies and storage. See the scrape-pages-behind-login recipe for an end-to-end walkthrough.
8

Do I still need a session for a single JavaScript-heavy page?

Not necessarily. If you only need one rendered page, the scraping API can render JavaScript in a single shot — pass stealth and let it run the page's scripts and action macros. Open a session when you need state to survive across multiple calls: an authenticated flow, a multi-step interaction, or repeated renders against the same site without logging in again.
1,000 free credits • Opening a session is free

Open your first session in five minutes.

1,000 free credits, one bearer token, opening a session is free, failed calls auto-refund.

Request access → Browse recipes →
No credit card required Managed stealth engine 124 endpoints live