For AI agents: a documentation index is available at /llms.txt
Skip to main content
Version: v2

Autologin

Autologin turns a 1Password service account into a ready-to-use Authenticated Profile with a single request. You give it a service account and a profile name; Browserless opens a session, signs in to your sites using the credentials from your vault, and saves the logged-in state as a profile you can reuse everywhere with ?profile=<name>.

It automates the "log in once, then reuse a profile" flow you would otherwise script by hand with Browserless.loadSecret + Browserless.saveProfile — the whole sign-in is driven for you, and as with all 1Password credential filling the secret values never reach your code.

When to use Autologin

Use Autologin when you just want a logged-in profile and don't want to write the login steps yourself. Use loadSecret directly when you need fine-grained control over the sign-in flow inside your own automation. Both resolve secrets from the same service account.

Prerequisites
  • A Browserless cloud account
  • A 1Password service account already connected to your API token
  • Login items in the connected vault, each with a website URL and a username/password (add a one-time-password field for sites with TOTP-based MFA)

How it works​

You send one request naming a service account and a profile name. Browserless then runs the login server-side:

  1. Open a session — Browserless starts a stealth browser session with the service account authorized, and signs in from a residential IP so the login isn't treated as datacenter traffic.
  2. Discover targets — it reads the Login items in the connected vault. Each item's website field is the origin to sign in to, and its username/password (and one-time-password, if present) are the fields to fill. Pass allowedDomains to log in to only a subset.
  3. Sign in — for each site, an automated login agent navigates to the login page and fills the credentials by reference, exactly like loadSecret: the value is resolved from 1Password and typed inside the session, and is never returned to your code, logged, or captured.
  4. Save a profile — once a site is signed in, Browserless captures the session's authenticated state (cookies, localStorage, IndexedDB) into an Authenticated Profile with the name you chose — the same capture Browserless.saveProfile performs.

The request returns immediately with a taskId; the login runs in the background. You poll the task for live progress and the final result.

The profile holds session state, not your password

The saved profile contains the signed-in cookies and storage — not your 1Password credentials. Reusing it replays that state; no secret is filled (or resolvable) from a session started with ?profile=<name>.

Starting an autologin​

  1. Open Profiles

    Go to Profiles in the dashboard sidebar. Under 1Password Service Accounts, find the service account you want to sign in with — its vault must hold the Login items for the sites you want.

  2. Create a profile

    Click Create profile on that service account. In the Create profile dialog, set a Profile name (this is what you'll pass as ?profile=) and pick the Sites to log into — every discovered site is selected by default; uncheck any you want to skip.

  3. Start and copy the connect URL

    Start it and watch each site sign in, with a live status line. On success the dialog shows a connect URL you can copy (a session URL with ?profile=<name>), and the profile appears under Authenticated Profiles, ready to reuse.

Tracking progress​

Poll the task by id. It reports its overall state, a live currentRationale (what the agent is doing right now), and the per-domain progress.

curl "https://production-sfo.browserless.io/integrations/onepassword/profile/autologin_eef23c512148b7198564ff49?token=YOUR_API_TOKEN_HERE"
{
  "taskId": "autologin_eef23c512148b7198564ff49",
  "state": "success",
  "currentRationale": null,
  "profileId": "profile_9b5c6923a7d631cdee36e259",
  "profileName": "acme-prod",
  "domains": [
    { "origin": "https://app.example.com", "status": "success" }
  ],
  "createdAt": "2026-06-18T12:00:00.000Z",
  "updatedAt": "2026-06-18T12:02:00.000Z"
}

state moves through:

StateMeaning
pendingAccepted, not started yet.
runningSigning in; watch currentRationale and domains[].status.
successAt least one domain signed in and the profile was saved — profileName is ready to reuse.
failedThe task ended without a saved profile — see errorCode / errorMessage.

Each entry in domains carries its own status: pending (not reached), active (currently attempting), tried (moved past, outcome pending), then the terminal success or failed (with an error).

const BASE = 'https://production-sfo.browserless.io';
const TOKEN = 'YOUR_API_TOKEN_HERE';

// Kick off the autologin.
const { taskId } = await fetch(`${BASE}/integrations/onepassword/profile?token=${TOKEN}`, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ name: 'acme-prod', integrationId: 'op_int_0a1b2c3d4e5f6a7b8c9d0e1f' }),
}).then((r) => r.json());

// Poll until it settles.
let task;
do {
  await new Promise((r) => setTimeout(r, 4000));
  task = await fetch(`${BASE}/integrations/onepassword/profile/${taskId}?token=${TOKEN}`).then((r) => r.json());
  console.log(task.state, task.currentRationale ?? '');
} while (task.state === 'pending' || task.state === 'running');

if (task.state === 'success') {
  console.log('Profile ready:', task.profileName); // reuse via ?profile=<name>
} else {
  console.error('Autologin failed:', task.errorCode, task.errorMessage);
}

Using the saved profile​

On success, the profile named <name> is a normal Authenticated Profile. Reuse it on any session by adding ?profile=<name> — the browser loads its cookies and storage before navigating, so the page opens already signed in.

import puppeteer from 'puppeteer-core';

const browser = await puppeteer.connect({
  browserWSEndpoint:
    'wss://production-sfo.browserless.io/chromium?token=YOUR_API_TOKEN_HERE&profile=acme-prod',
});

const page = await browser.newPage();
await page.goto('https://app.example.com'); // already logged in

Because a reused profile fills no secret, the session isn't locked down — screenshots, PDFs, and page reads all work normally. When credentials rotate or the session expires, re-run the autologin for the same name to refresh the profile.

Security​

Autologin inherits the 1Password security model:

  • Secrets stay server-side — credentials are resolved from 1Password and typed inside the session; they're never returned to your code, logged, or captured.
  • Origin safety — credentials are only ever typed into public https:// origins; http:// and private/internal addresses are always refused. If the service account sets an allow-list, sign-ins are limited to it (by default, with no list, any public https origin is allowed); allowedDomains on the request can narrow a run further.
  • Locked-down capture during login — once a credential is filled, the sign-in session blocks screenshots, PDFs, and page reads, tears down live URLs, aborts any in-progress screen recording, and scrubs the filled values from logs and the session replay — so the typed value can't leak. The saved profile is captured through the same trusted path.
  • Audit log — each credential resolve is recorded (reference, origin, outcome) — never the value.
  • Token-scoped — tasks and profiles are scoped to your API token; other tokens can't see or reuse them.

Failure modes​

If the request is rejected, it returns an error before a task starts:

StatusWhen
400name or integrationId missing, allowedDomains isn't an array of origins, an origin isn't one of the service account's login origins, or a profile with that name already exists.
404The integrationId is unknown, expired, or unreachable.
503The service account or 1Password is temporarily unavailable — retry.

Once running, a task that can't finish ends in state: "failed" with an errorCode:

errorCodeMeaningWhat to do
AllDomainsFailedEvery targeted site failed to sign in — check each domains[].error.Verify the Login items resolve and the credentials/selectors are valid; retry.
AutologinTimeoutThe sign-in didn't complete within the time budget.Retry; a slow site or an extra step (MFA, interstitial) can exceed the budget.
AgentErrorThe login couldn't be completed or the profile couldn't be saved.Retry; if it persists, contact support.

Per-domain error values reuse the loadSecret failure codes (for example CredentialNotResolved, DomainNotAllowed, SelectorNotFound) so you can see exactly why a site didn't sign in.

FAQ​

How is Autologin different from loadSecret?

loadSecret fills one referenced field into a selector you choose, inside your own automation. Autologin drives the entire sign-in for you across the service account's Login items and saves a reusable profile at the end. Both resolve secrets from the same service account and never expose the value.

Does it handle multi-factor authentication?

If the Login item has a one-time-password (TOTP) field, autologin can use it. It can't complete out-of-band factors like SMS codes or push approvals.

The profile name already exists — what happens?

The request is rejected with 400. Pick a new name, or delete the existing profile first. To refresh an existing profile, delete it and re-run the autologin with the same name.

Can I sign in to only some of the service account's sites?

Yes. Pass allowedDomains with the subset of origins you want. Each value must be one of the service account's login origins.

Further reading​