The Problem with One-Size-Fits-All

When you point an extraction API at a URL, you typically have no say in how the page gets fetched. A static documentation page and a JavaScript-heavy single-page application go through the same pipeline, with the same overhead and the same latency. You end up paying a time penalty on simple pages because the system has to assume every page might be complex.

The reality is that most pages on the web are straightforward. A news article, a product listing on a server-rendered site, a wiki page — these do not need a full headless browser to extract. But a React dashboard behind client-side rendering absolutely does.

You know your target sites. We should let you tell us.

What Changed

We made two changes to how Tabstack handles page fetching.

First, we rearchitected the default fetch path to be significantly faster and more reliable. The "standard" effort level that every request uses by default is now smarter about how it retrieves content, with better fallback mechanisms and reduced overhead.

Second, we added the effort parameter to the /extract/json, /extract/markdown, and /generate/json endpoints. This gives you explicit control over how hard Tabstack works to fetch a page before extraction begins.

There are three levels:

"min" — A lightweight fetch with no fallback. This is the fastest option usually under 1 second, ideal for static or server-rendered pages where you know the content is available without JavaScript execution.
"standard" — The default. A balanced approach with enhanced reliability and fallback mechanisms, typically completing in less than 10 seconds. This will handle most pages, including ones with some JavaScript. Start here for any new integration.
"max" — Full browser rendering. This spins up a headless browser, executes JavaScript, waits for dynamic content to load, and then extracts. It takes 15 to 60 seconds but is necessary for SPAs, pages behind client-side hydration, or sites that load content dynamically. Try this when the other levels are not getting the content you want.

Using Effort

Adding the parameter is straightforward. Here is a basic example that extracts markdown from a JavaScript-heavy page:

import os
from tabstack import Tabstack
 
client = Tabstack(api_key=os.environ.get("TABSTACK_API_KEY"))
 
# Full browser rendering for a JS-heavy page
result = client.extract.markdown(
    url="https://example.com/spa-dashboard",
    effort="max"
)
 
print(result.content)

For a static docs site where speed matters, drop to "min":

result = client.extract.markdown(
    url="https://docs.example.com/api-reference",
    effort="min"
)

Adaptive Effort: Start Fast, Escalate When Needed

The most powerful pattern with the effort parameter is adaptive escalation. Instead of guessing the right level upfront, you start with the fastest option and only escalate when the result is insufficient. This gives you the best possible latency on easy pages while still handling complex ones reliably.

import os
from tabstack import Tabstack
 
client = Tabstack(api_key=os.environ.get("TABSTACK_API_KEY"))
 
def extract_with_adaptive_effort(url, min_length=100):
    """Extract markdown, escalating effort until we get a good result."""
    efforts = ["min", "standard", "max"]
 
    for effort in efforts:
        result = client.extract.markdown(url=url, effort=effort)
 
        if result.content and len(result.content) >= min_length:
            return result
 
    return result  # Return whatever we got at max effort
 
result = extract_with_adaptive_effort("https://example.com/products")
print(result.content)

This pattern works well in production pipelines where you process a mix of sites. Simple pages resolve in a couple of seconds at "min", and only the pages that genuinely need browser rendering incur the additional latency. Your average response time drops significantly while your success rate stays high.

When to Use Each Level

Here is a quick guide for choosing the right effort level:

Use "min" when you are scraping well-known static sites, server-rendered pages, or any URL where you have verified that lightweight fetching returns complete content. Great for high-volume pipelines where speed is critical.
Use "standard" when you are integrating with a new site or processing a mix of URLs. It handles most of the web reliably without the overhead of full rendering.
Use "max" when content is missing from lower effort levels, the target is a known SPA or JavaScript-heavy application, or the page loads data asynchronously after initial render.

Get Started

The effort parameter is available now on all extract and generate endpoints. Update to the latest SDK version to use it, or pass effort directly in your request body if you are calling the API without an SDK.

API Reference: docs.tabstack.ai
Tabstack Dashboard: tabstack.ai

If you are building pipelines that process diverse URLs, try the adaptive effort pattern. Start fast, escalate smart, and let your code decide how hard to try.

Not Every Page Needs a Browser