Skip to main content
Build your own credential collection UI instead of using the hosted page. Poll for login fields, then submit credentials via the API. Use the Programmatic flow when:
  • You need a custom credential collection UI that matches your app’s design
  • You’re building headless/automated authentication
  • You have credentials stored and want to authenticate without user interaction

How It Works

1

Create Connection and Start Session

Same as Hosted UI
2

Poll and Submit

Poll until flow_step becomes AWAITING_INPUT, then submit credentials
3

Handle 2FA

If more fields appear (2FA code), submit again—same loop handles it

Getting started

1. Create a Connection

A Managed Auth Connection attaches an authenticated domain to a profile so you can use the auth connection in future browsers. A single profile can hold multiple auth connections — create one connection for each domain you want to keep authenticated on that profile.

2. Start a Login Session

Credentials are saved automatically on successful login, enabling automatic re-authentication when the session expires.

3. Poll and Submit Credentials

A single loop handles everything—initial login, 2FA, and completion:
The discovered_fields array tells you what the login form needs:

Complete Example

This example covers username/password login with 2FA — the most common flow. If the site uses SSO, MFA selection, account pickers, or external actions (push notifications), see Handling Different Input Types below for how to handle each case.
Every programmatic login session also has a hosted_url. If your flow encounters an unexpected state, you can redirect the user to this URL to complete login via the Hosted UI instead.

Handling Different Input Types

The basic polling loop handles discovered_fields, but login pages can require other input types too.

SSO Buttons

When the login page has “Sign in with Google/GitHub/Microsoft” buttons, they appear in pending_sso_buttons:
Common SSO provider domains (Google, Microsoft, Okta, Auth0, GitHub, etc.) are automatically allowed. For custom OAuth providers, add their domains to allowed_domains on the connection.

SSO Provider Selection

As an alternative to clicking an SSO button by selector, you can submit the SSO provider name directly. When SSO buttons are detected, the session state includes a sso_provider field (a string) identifying the provider that Kernel recommends. You can also specify a provider explicitly using the sso_provider submit parameter:
sso_provider is a singular string value, not an array. Use sso_button_selector when you need to click a specific button by its CSS selector, and sso_provider when you want to identify the provider by name (e.g., "google", "microsoft", "okta").

MFA Selection

When the site offers multiple MFA methods, they appear in mfa_options:
After selecting an MFA method, the flow continues. Poll for discovered_fields to submit the code, or handle external actions for push/security key.
The switch type represents generic method-switcher links like “Use another method” or “Try another way” that don’t name a specific factor. Submit it the same way as any other MFA option to reveal the underlying alternatives on the next page.

Sign-In Options (Account/Org Pickers)

Some sites present non-MFA choices during login, such as account selection or organization pickers. These appear in sign_in_options as an array of objects with id, label, and optional description:
Sign-in options are distinct from MFA options. MFA options (mfa_options) represent second-factor authentication methods like SMS or TOTP. Sign-in options represent non-security choices like “Which account do you want to use?” or “Select your organization.”

External Actions (Push, Security Key)

When the site requires an action outside the browser (push notification, security key tap), the step becomes AWAITING_EXTERNAL_ACTION:
mfa_options, pending_sso_buttons, and sign_in_options may be populated during AWAITING_EXTERNAL_ACTION when the site exposes fallback methods alongside the external action (for example, “Try another way” on a push prompt). Submit one of them to switch verification methods, or keep polling to let the user complete the external action.

Step Reference

The flow_step field indicates what the flow is waiting for:

Status Reference

The flow_status field indicates the current flow state: The status field indicates the overall connection state:

Connection Configuration

Connection-level options — custom login URL, SSO/OAuth, custom proxy, session recording, post-login URL, and updates — apply equally to all integration flows and are documented in Connection Configuration.

Real-Time Updates with SSE

For real-time UIs, you can stream login flow events via Server-Sent Events instead of polling:
The stream delivers managed_auth_state events with the same fields as polling (flow_status, flow_step, discovered_fields, etc.) and terminates automatically when the flow reaches a terminal state.
Polling is recommended for most integrations. SSE is useful when building real-time UIs that need instant updates without polling delays.