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.

@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.

@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.

@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.

@galdayan Good distinction. Within a single /automate call it's one live browser session, so a cookie set in step one is still there in step two. Multi-step flows that depend on earlier state work fine inside one task.

Across separate calls it's stateless: no built-in session store, and no param to pass auth state back in, each call starts clean. So the pattern that works is doing the whole logged-in flow in one task, not logging in on call one and trying to reuse it on call two. The hosted API isn't built to manage credentials or hold a login across jobs—not yet anyways.

@attacomsian Thank you, that means a lot.

Bot detection: not abstracted away, not on you either. We run real browsers and respect robots.txt by default, so ordinary checks are usually fine. We don't do stealth or CAPTCHA-solving. If a site is set on keeping automation out, we won't fight it. That's a Mozilla call.

And yes on the accessibility tree. It's a cost decision as much as a reliability one, and screenshots get expensive fast. Glad that stood out.

@dipankar_sarkar Exactly right, and honestly that guard living on your side is the stronger design anyway. Idempotency belongs with whoever owns the write, not the tool making the call, so a cheap existence check before submit means your retry safety holds no matter what we do or don't persist. One extra read to dodge a duplicate order is a trade I'd take every time. Appreciate you sharing how you landed on it.