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

@starchet we're actually going to show off those kinds of use cases on our livestream later today! Currently, we don't have credential or session management, so the authentication into your social channels would be the trickier part. However, if you had a wrapper around Tabstack that you were feeding auth keys or cookie sessions to, it should work really really well. Watch our YouTube for the livestream—should be in 4 or so hours: https://www.youtube.com/@tabstackdev

Is it fair to think of Tabstack as browser automation powered by AI?

Correct. Extract structured data to a schema you define, convert pages to Markdown, run cited multi-source research, and automate browser tasks using @Tabstack by Mozilla.

The key differenciator? @Mozilla. Every call runs on a Mozilla-backed platform. The pages you extract, the answers you research, and the tasks you automate stay yours, handled responsibly and never used to train models.

Private by default, transparent by design. @Tabstack by Mozilla is just different.

@zain_sheikh Honest answer: it doesn't silently switch to a pixel/vision mode when the tree is thin. /automate works from the accessibility snapshot, so if an interactive element is genuinely absent or mislabeled in the tree (canvas-drawn controls, unlabeled divs with click handlers), the agent can't reliably target it and that step will struggle rather than fall back to vision.

So the tradeoff is real in both directions: on structured, semantically-labeled pages you get the token savings and reliability; on pixel-only or canvas-heavy UIs, a tree-based approach is weakest, and we won't paper over that today. If your workflow lives mostly in that canvas-heavy territory, it's worth testing on your actual target pages before you commit.

@dipankar_sarkar Each /automate call is stateless and self-contained. There's no checkpoint and no resume-from-step, so if a task dies at step three, retrying the call starts a fresh run from the top rather than picking up where it stopped.

Worth knowing: it's goal-driven, not a recorded macro. A retry doesn't blindly replay "click X, then click Y" from a saved log; the agent re-plans from the live page state toward the task. So it won't automatically re-run steps one and two as a fixed script. But that's not an idempotency guarantee either. Nothing on our side dedupes a form submit or a confirm click, so if the page state after a partial run is ambiguous, a retry can still re-fire an irreversible action.

For anything that submits or confirms, that means don't rely on the retry to be safe. Keep the destructive step idempotent on your end (an idempotency key, or a check that it already happened) and it's a non-issue.

@thys_beesman There's no separate concurrency cap. What governs parallel tasks is a per-minute request rate limit, and it's per account (shared across every API key and every endpoint, not per key or per endpoint):

• Trial / Individual: 10 requests/min

• Team: 25 requests/min

• Pro: 100 requests/min

Every response carries X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset, so the clean pattern is to read X-RateLimit-Remaining off your successful calls and throttle before you hit zero. If you do go over, you get a 429 with a Retry-After header, and the SDKs retry that automatically with backoff.

So fire off as many tasks in parallel as you like: the limit you'll actually bump into is requests per minute, not a fixed number of concurrent connections.

@campak Yeah, fully hosted: the browser runs on our infrastructure, so you just call the API and get the result back, nothing to run on your side.

Auth flows are the honest edge of the hosted API. It's stateless per call and doesn't manage sessions or credentials, so an interactive login (OAuth, "Sign in with Google," anything that hands back a session you need to hold onto) isn't something it carries across calls. It's built for public pages. Two ways people handle that:

1. Run the engine locally. /automate is powered by Pilo, our open browser-automation engine. Run it in your own environment, complete the login yourself, and it drives your authenticated session directly. That's the right path when the task genuinely needs to be signed in.

2. Split the work. Keep the authenticated steps in your own code and point hosted Tabstack at whatever's reachable without a session. You own the login; Tabstack does the structured extraction and automation around it.

Thanks, glad it caught your eye!

@soumya_ranjan_mohapatra thanks! It fails fast with a clear signal. A disallowed URL comes back as a 422 with the message blocked by robots.txt, surfaced in the SDK as a typed UnprocessableEntityError, so you can catch that specific case and reroute (skip the URL, try an allowed path, hand it back to your planner) instead of guessing. It's synchronous on the call, and it fires the same way mid-/automate, so an agent hits the boundary the moment it tries the page, not later.

One detail worth knowing: the check fails open. If a site's robots.txt can't be fetched or parsed, the request proceeds rather than blocking, so you only get the 422 on an actual disallow, not on an ambiguous or missing file.

Compliance is on by default, so this is the intended behavior rather than something you configure.

@dipankar_sarkar Straight answer: no, there's no do-once or idempotency-key primitive today. A run is stateless with no persisted step ledger, so on a retry there's nothing server-side for it to consult and skip against. Your instinct is the correct one, and honestly the target is the only place a true do-once can live, since it's the only party that can guarantee the no-op. An idempotency key that the target honors is exactly right.

One softer lever in the meantime: since the task is natural language, you can fold the guard into the task itself and have the agent check for the post-submit state (a confirmation page, an existing record) before it acts. That's best-effort model judgment, not a guarantee, so it complements your idempotency key rather than replacing it.

It's a sharp ask, though. A first-class "mark this step do-once" is a genuinely useful primitive for write-heavy agent loops, and I'll flag it to the team.

@mark_toubman2 🙌

@toprak967471 Thank you, that's the best kind of surprise to hear about. And the robots.txt default isn't an accident, it's the Mozilla way. We think agents should access the web the way it asks to be accessed. Respecting that by default matters more to us than shipping a bypass. Appreciate you noticing it.