Skip to main content

​
How does automatic re-authentication work?

with health checks and automatic reauthentication enabled, KERNEL attempts reauthentication when a scheduled health check confirms that an eligible connection is logged out. can_reauth: true means eligible to attempt, not guaranteed to succeed. stored credentials and an available totp secret can support unattended login, but a new code, choice, or approval that requires a user can leave the connection in NEEDS_AUTH. your application must start a new interactive login when user input is required. see connection lifecycle for cadence options and eligibility rules.

​
Can managed auth automatically handle email or sms verification?

not during unattended reauthentication. if a site requires an email or sms code, your application must start a new interactive login and bring the user back to provide it through the hosted ui, react component, or programmatic flow. wait for successful authentication before resuming the automation. a code supplied during an earlier login doesn’t give KERNEL access to future codes.

​
What are auth choices?

Auth choices are visible routes a site presents during login, including mfa methods, sso providers, account pickers, and organization selectors. They appear in the canonical choices array. Submit the exact returned id with interaction_id and selected_choice_id. See the programmatic flow guide for examples.

​
Which authentication methods are supported?

managed auth supports common credential, sso, and multi-step interactive login flows. automatic reauthentication is limited to eligible flows that can complete without human input. KERNEL can generate totp codes from an available secret; email and sms codes, approvals, and other user-required steps need an interactive login.
Passkey-only authentication isn’t currently supported. If a site’s SSO provider requires a passkey, the login returns unsupported_auth_method. Switch the account to a supported sign-in method, such as password and TOTP, then start a new login.

​
What happens if login fails?

Kernel surfaces an error code (credentials_invalid, account_locked, bot_detected, captcha_blocked, etc.). Transient site failures are retried; a conclusive rejection by the site isn’t, so Kernel doesn’t burn attempts against a locked account or resubmit credentials the site already refused. See Connection Lifecycle for the full list and recovery steps.

​
Can I use Managed Auth with any website?

Managed Auth covers common login flows across a broad range of websites. Site-specific authentication and bot detection can require additional configuration. See what Managed Auth supports and test your target flow.

​
Is Managed Auth available during a trial?

Yes. Managed Auth and browser profiles are available during your trial period with the same capabilities as the plan you’re trialing.

​
How do I verify a connection before starting a task?

call .login() as a pre-task authentication check, then follow the connection until the flow reaches SUCCESS. when the connection has a saved auth check url, KERNEL verifies the existing session before attempting a login. if the flow pauses for user action, continue the same flow through the returned hosted_url; don’t call .login() again, because that cancels the flow in progress. don’t gate the task only on the connection’s current status, which reflects its latest completed health check. see verify authentication before starting work for the full pattern.

​
What types of flows does Managed Auth support?

Managed Auth navigates login pages, enters stored credentials, follows SSO redirects, guides users through additional authentication steps, and saves the resulting browser session. For post-login work like form filling, sign-ups, or other workflows, use Kernel’s browser automation directly.

​
How do I debug a managed auth session?

Use the Browser Sessions tab in the dashboard for live view, or set record_session: true to capture replays of every auth browser session. See Debugging a flaky connection for details.

​
Can I attach multiple auth connections to one profile?

Yes. A profile can have any number of auth connections, each for a different domain. When you create a browser with that profile, it loads the saved authentication state for every connected domain. This is useful for two common patterns:
  • Multi-site workflows — Your agent visits multiple sites in a single run (e.g., reads email in Gmail, posts a summary in Slack, and updates a CRM). Attach one auth connection per site to a single profile, and each browser loads the saved authentication state for all of them.
  • User-to-profile mapping — Each end user on your platform gets one profile. All of that user’s accounts (Gmail, LinkedIn, GitHub, etc.) are auth connections on their profile. When the user triggers a workflow, launch a browser with their profile.
See Reuse one identity across sites for code examples.

​
How is Managed Auth billed?

Managed Auth is included on all plans with no per-connection fees. It uses browser sessions for login, health checks, and eligible reauthentication attempts. These count toward your browser usage like any other browser session. Auth sessions are fast (typically 5-30 seconds each). Kernel monitors session health and can automatically reauthenticate eligible credential-based flows when sessions expire. Most sessions stay valid for days. For example, monitoring 100 auth connections typically costs less than $5/month in browser usage. See Pricing for details.