The questions we get asked first.

No. You type it into the site’s own login page during capture, in a browser, over the site’s TLS. We keep only the session the site issued afterwards. There is no code path that persists a password.

The session material the site handed back after a successful login: cookies (including HttpOnly, which page JavaScript can never read), and localStorage for each origin in play. All of it is encrypted under your tenant’s key before it touches disk.

Two differences, and the second is the one that matters in practice. First, a stolen password is permanent and reusable; a session can be revoked and expires on its own. Second, a credential-replay bot has to defeat MFA, CAPTCHA, SSO redirects and bot detection on every run. We skip the login entirely, so there is nothing to defeat.

We do not solve one-time passwords. You complete the OTP once, by hand, during capture. Every run after that reuses the resulting session, so there is no OTP to solve. If your portal requires step-up auth on every sensitive action, that workflow is a poor fit and we will say so.

Same answer. CAPTCHAs appear at login, which you do once, as a human. We do not break or solve CAPTCHAs, and we will not help circumvent bot protection to gain access.

Yes, and this is where most automation falls over. Identity providers render their login inside a cross-origin iframe, which ordinary browser automation cannot address. We can read, type and click inside those frames, which is why the capture works on a normal SSO flow.

During capture, yes, you sign in yourself, on your machine or in a session we host for that purpose. You never hand us credentials. After capture, the agent acts using the session you granted it.

Your tenant’s data encryption key decrypts them. That key is wrapped by a master key held in your cloud’s secret manager or KMS. In a self-hosted or Enterprise deployment, we hold none of it.

An attacker gets ciphertext and no usable key. The master key is not in the database, not in the image and not in instance metadata. Each record is also bound to its tenant, so ciphertext cannot be replayed in another tenant’s context.

Not yet. We are not going to imply otherwise. We will share our architecture and controls with your security team in the meantime, and Enterprise customers can run the whole thing inside their own cloud.

Yes, from the console or the API. Revocation takes effect before the next run; subsequent runs refuse to start rather than failing halfway.

No. Each run creates a fresh browser context with no cookies, storage or history, injects the session, and destroys the context when it finishes. Parallel runs on the same session cannot see each other.

Every privileged action is logged (provisioning, capture, revocation, key rotation and every run) with actor and target. It is queryable via the API and visible in the console.

Yes, on Enterprise. The runtime is a container; point it at your container platform and your KMS and it runs there.

The run fails with a clear reason rather than silently scraping a login page. The session is flagged for re-capture, you sign in again, once, and automation resumes. Session lifetime is set by the portal, not by us.

That depends entirely on the portal. Banking sessions often last weeks; some government portals expire in thirty minutes. We will tell you honestly what your portal does before you commit to a pilot.

The step list targets the semantic accessibility tree, not pixel coordinates, so most cosmetic changes are absorbed. Structural changes break runs, the same way they would break a person’s muscle memory, and the fix is a step edit, not a rewrite.

Yes. Runs can be scheduled or triggered on demand, and results can be delivered by webhook. That is the entire point.

Assertions. assertText and assertLoggedIn fail the run loudly instead of returning an empty result set that looks like a quiet month. Every run keeps its step-by-step record.

No. Headless Chromium in a container. That is what makes parallel runs cheap.

Yes, and it is the primary interface. The console is a client of it. Sessions, captures, runs and audit are all available over HTTP with a tenant API key.

$490 per month: one portal, one workflow, up to 500 runs. Month to month, no setup fee.

No. Only completed runs are billed, so you can afford generous timeouts.

The pattern we support is automating access you are entitled to, your own filings, your own bank statements, your own claims, on a site that offers no programmatic alternative. We do not circumvent authentication or bot protection, and we will not design around a terms-of-service restriction that binds you. Check the specific portal’s terms; if it prohibits automated access, that is your contract to honour.

Yes, run history and the full audit log. No exit fee.

PreLogin is a product of DataDab LLP. It is proprietary software, not open source.

It probably still works. The ten are the ones we see most often, not a limit on the runtime. Describe the workflow and we will tell you straight.