Data behind a login, reached programmatically.
The data worth having is usually behind a login. Automating that normally means putting credentials in a config file and hoping nothing challenges you.
- No credit card required
- Free plan to start
Why authenticated automation is risky
- Storing credentials for a third-party system is a liability.
- Two-factor breaks unattended logins.
- Sessions expire and the job fails at 3am.
- Repeated logins from a datacenter look exactly like an attack.
How Browza handles it
No credentials in your code
A human signs in once through live takeover; the resulting session is stored encrypted as a profile.
Passwords are never typed by Browza
The authentication step is performed by the person, not by the agent — there is nothing for us to leak.
Sessions persist
Later runs reuse the profile and arrive already signed in, which also means far fewer challenges.
Re-auth is a hand-off
If a session lapses, the run can pause for a person rather than failing the batch.
How you'd call it
A goal and a schema over HTTP — no selectors to maintain and no browser fleet to run.
“Create a profile, sign in once via the live view, then reference config.profile on every later POST /v1/runs.”
Questions people ask
Where is the session stored?
Encrypted, scoped to your workspace, and revocable at any time. It is a browser session, not a password.
What about two-factor?
The initial sign-in is done by a person, so 2FA is handled naturally. Because sessions persist, it is rarely asked again.
Can two runs use the same profile at once?
No — a profile is leased to one run at a time, so two runs can't corrupt one signed-in session. A waiting run is queued rather than failed.
Related use cases
What will you hand over?
Start with one task. Watch it run, take the wheel whenever you want, and keep the ones that earn their place.