Autocapture and Custom Events

Corbado Observe supports Autocapture and custom events. On web, start with Autocapture and add custom events for additional context. For authentication implemented natively, use custom events with the native SDKs. Both feed the same data model and views.

​

1. Autocapture

Recommended for web. Autocapture is the default integration path. You deploy the Observe JavaScript snippet with Autocapture built in. Corbado configures its selectors and capture rules to recognize your authentication steps from signals your frontend already emits. Your team does not need to tag individual events or change the login flow; Corbado maintains the capture configuration as it evolves.

​

1.1 What Autocapture actually does

Autocapture observes five types of browser signals: Those raw signals are then mapped onto your actual flows, so which request means “identifier accepted” and which button means “user chose password over passkey”. They arrive in Observe as a modeled journey rather than a stream of clicks. Autocapture is built on @corbado/autocapture, a dependency-free capture library designed to run inside a page it does not own and to fail closed when a browser surface cannot be instrumented safely. Corbado tunes the Autocapture configuration for your flows during onboarding: which selectors, requests, states and transitions identify each authentication step. Corbado maintains these capture rules as your login evolves. Talk to us to get started.

​

2. Custom events

Custom events are explicit Corbado Observe events you emit from your own code, at the semantically correct points in your flows. You define the granularity. Custom events are required for authentication implemented with native platform APIs; web-based login components in mobile apps can use Autocapture. Section 3 explains exactly when you need them. See Custom events to send your first one, and the tracking reference for the full data model.

​

3. Where Autocapture stops

Autocapture coverage depends on signals observable in the browser. Autocapture can work with anything that is visible in the browser or reported back to it: rendered UI states, user interactions, WebAuthn ceremonies, navigation and the shape of requests and responses. From those signals the configured capture rules derive the product meaning, including which method a user chose, whether an identifier was already known, whether a ceremony was a login or an enrollment and whether the user or the system started a step. Custom events are for facts that never reach the browser, or that you want pinned rather than derived: Where a custom event needs to join a journey that started in the browser, it is correlated using an ID you already have, such as a challenge or transaction ID, otherwise the Observe session ID.

​

4. Combining both on web

Running Autocapture and custom events together on web is a supported setup, sometimes called a hybrid integration. Autocapture provides the baseline journey and you add events only for the gaps that matter, including enrichment from your backend. Both write into the same project, the same session and the same data model, so the added events appear inside the same journey rather than beside it. Because the exact wiring depends on how your Autocapture bundle is delivered, set this up together with us rather than adding a second SDK instance to the page.

​

5. Choosing between them

What we recommend:

• Web: start with Autocapture, then add custom events for the gaps in section 3.
• Native authentication: custom events with the iOS or Android SDK. Web-based login components can use Autocapture.
• Both web and native apps: Autocapture for web journeys and custom events for native authentication. One project holds all three channels, and applications keep them comparable.

​

6. Next steps