Tabstack Browser Automation - Automate the web in your app or agent, no browser to host

@bavcichali87886 Thanks for getting into the mechanics, this is the right question to ask.

JS-heavy SPAs: these run on a real browser under the hood, not a plain HTTP fetch, so client-rendered content works. If a page loads its data lazily or after interaction (pricing tables, product grids, dashboards), set effort to max. That's full browser rendering built for exactly this case. standard is faster but can return empty fields on the heaviest SPAs, so max is the lever when you see that happen.

Anti-bot: Tabstack is built by Mozilla and respects robots.txt by default, so it's made for accessing the open web, not for defeating sites that don't want automated access. Real browser rendering plus geo-aware routing (geo_target) handles a lot of what trips up naive HTTP clients, but aggressive stealth and CAPTCHA-solving aren't what we do. If your use case leans on that, I'd rather tell you now that we're probably not the right fit.

If you've got a specific URL that's giving you trouble, send it over and I'll take a look.

@azadfndk143609 robots.txt is respected by default, and it's checked per URL against the user-agent, not as a blanket on/off. If a site's robots.txt disallows the path you're pointing at, Tabstack treats it as blocked and won't fetch it. There's no compliant bypass, that's deliberate on Mozilla's side. In /research you'll even see blocked URLs counted in the robotsBlocked stat.

The part that usually matters: robots.txt is path-specific, so sites rarely disallow everything. The page you actually want is often allowed even when other parts of the site aren't. So it's less "the API refuses you" and more "it respects exactly what the site published."

And worth separating, since people lump them together: a robots.txt disallow is different from a page throwing bot-detection at you. Only the first is a robots.txt question. If you hit blockers, share the URL and I'll tell you which you're hitting.

@zafer175063 If robots.txt disallows the path, we don't fetch or render it, whether or not the data would technically be sitting in the DOM. "Technically accessible" isn't the same as "allowed," and we go by allowed. That's the Mozilla line, we won't route around a site's stated policy. If the path isn't disallowed, the agent reads it normally.

@zgurbuzogl23098 JS-only content is the easy part: /automate runs a real browser and interacts with the page (click, scroll, fill, submit), so anything that only appears after render or interaction works.

On heavy bot protection, we respect robots.txt by default and don't do stealth or CAPTCHA-solving, so if a site is actively locking out automation, we're not the tool to beat it.

Pricing is usage-based, not a flat tier. A Markdown fetch is 10 credits (one action). /automate is 100 credits per action and runs as many actions as the task needs, so an interactive task costs more than a plain fetch, and a longer task costs more than a short one. You see the per-action rate before you run it.

@nazls86733 thank you! I actually built an app with Tabstack doing the same thing. I'm using extract and generate, though. I feed it the recipe url, it extracts the data, then generates a clean, easy to follow recipe. Most of the ones online are such a mess to read with ads, and otherwise. Glad you found success. Hopefully you can find more ways to integrate it. I have it available to my Hermes agent so its constantly grabbing for it to do various things I ask it to do as the tool to surface the data and navigate the web.

@nehir238420 amazing! feel free to add your review here: https://www.producthunt.com/products/tabstack/reviews/new

@nehir238420 incredible! That's awesome to hear.

@aidanhornsby its amazing. We did a live stream this afternoon where I showed off my Hermes agent doing this very thing. All of the Tabstack endpoints are super helpful for agents. I'm currently building an enrichment tool with CRM sync using Tabstack in the stack multiple times. Its for my local OS and my agent. Fast-forward until you see a Telegram window.

@david_marko Thank you, that means a lot. You nailed the bet: that accessibility-tree read is exactly how the automate agent perceives a page, so it stays steady when a layout shifts instead of breaking the way a screenshot agent does.

And messy contact/booking pages with no API are a great thing to point it at. /automate navigates and reads the page structure, so you hand it the task in plain language and it works the page and pulls what you asked for. If you aim it at one of the pages your agents lose the thread on today, I'd love to hear how it holds up.

Thanks for the support, David! And please keep us posted about your experience using @Tabstack by Mozilla. Looking forward to what you're building.

@perihan69108 Client-side rendering is handled: it runs on a real browser on our side, so JS-heavy and SPA content that only appears after render works, and yes, no browser infra for you to run. If a page is especially heavy, bumping effort to max gives it full rendering room.

Sites that actively block headless or automated access are a different story: we run real browsers and respect robots.txt by default, and we don't do stealth or CAPTCHA-solving. Ordinary bot checks are usually fine, but if a site is genuinely determined to keep automation out, we're not the tool to force it.

@mirag1jy By default, gone the second the response lands. The payloads (URL, parameters, response data, extracted output) are discarded as soon as the call completes and never stored. What persists is request metadata: which endpoint you hit, success or failure, timestamp, credits. So you can see that a call failed, you just can't replay its contents.

If you need payload-level debugging, detailed data collection is opt-in per org. Turn it on and those payloads are retained for 90 days, then dropped. Interactive form values stay ephemeral either way, they expire in minutes and are never stored.