Skip to main content
This page answers the question every engineering team asks first: will this work with our stack, and what does it do to our application?

​
1. What Observe requires

There is no backend integration, no server-side SDK, no IdP configuration and no change to your authentication logic. Observe works the same whether you run a commercial IdP, an open-source WebAuthn library or a custom in-house implementation. See what Observe is not.
Observe is telemetry only. It is not in the authentication path and cannot grant, deny, delay or alter a login. An SDK failure, a blocked request or a missing configuration costs you telemetry, never an authentication.

​
2. Platform support

JavaScript-based mobile frameworks such as React Native with Expo, Ionic or Capacitor authenticate through a web surface and are covered by the web integration wherever the login runs in a web context. Where a framework routes passkeys through a native platform API instead, use the native SDK for that platform.
Native SDKs send into the same data model as the web SDK, so web and app journeys are comparable in the same project. Keep them apart with applications. App authentication behaves differently enough from web that the metrics worth tracking differ too: see Native app authentication analytics.

​
3. Iframes and RP IDs

If your authentication runs inside an iframe, which is common for embedded login and embedded wallets, two things matter:
  • The SDK must run in the frame that performs the ceremony. navigator.credentials calls are observed in the document that makes them, not in the parent.
  • The iframe must be permitted to perform WebAuthn. A cross-origin iframe needs the publickey-credentials-get and publickey-credentials-create permissions policy for passkeys to work at all. That is a requirement of your own implementation, not of Observe, but it is the first thing to check when ceremonies appear to be missing.
See the guide on relying party IDs for background on RP ID scoping.

​
4. Data handling

Observe does not need PII to do its job. It collects no names, email addresses, phone numbers or other directly identifying attributes; the only identity-linked value is the user reference you choose to pass, and that can be pseudonymous. Never collected: passwords or any other typed input, form field contents, session tokens or credentials for your own system. Collected:
WebAuthn responses are inherently identifying: they contain credential IDs, user handles, challenges, signatures and authenticator data. Observe collects the fields it needs for authenticator and credential insight. If you must not send user handles or credential IDs to a processor, raise this before integration so the collection profile can be scoped accordingly.
You control identity. The user reference is a value you pass. Pass a pseudonymous or hashed identifier and Observe never sees a real user ID.

​
5. Autocapture limitations

Autocapture observes the browser surfaces listed under what Autocapture actually does. Where it stops:

​
6. Browser and OS support

If you need a documented floor for older Android WebViews, legacy Edge or specific enterprise browser versions, ask us. The tested matrix is expanding and we would rather give you a precise answer than a marketing one.
SDK storage and cross-tab locks are scoped by project ID. The storage option selects storage for device identity; it does not move all SDK state into cookies: Session storage holds the per-tab session. Local storage holds configuration, pending events and, when server-controlled session continuity is enabled, the shared session and sequence counter. Cookie mode still uses these browser stores and does not make sessions shared across origins. The SDK checks inactivity when it initializes. A dated per-tab session that has reached its inactivity window gets a new ID at that point; continuity sessions also expire at initialization. Tracking refreshes activity, but inactivity alone does not rotate the ID within a running page. A long-lived page can therefore outlive the inactivity window. With continuity enabled, a tab can adopt a shared session ID changed by another tab. The inactivity window is server-controlled, not an initialization option. An Observe session is a telemetry grouping, independent of your application’s authenticated session. If a flow continues across page loads, its inactivity window must span that journey. On upgrade, a valid legacy bare session ID is preserved and dated when first read, rather than immediately split. Follow the upgrade instructions when introducing multiple projects. Observe stores no advertising identifiers and does no cross-site tracking. Whether your consent management platform needs to gate the SDK is your own legal assessment. If it does, initialize Observe after consent and journeys before that point are simply not recorded.

​
8. Projects, environments and hosting

Keep environments in separate projects. Production, staging and development should not share a project, because mixed data makes funnels meaningless. Use applications to separate channels of the same product and tags for further dimensions. Observe runs on Corbado’s public cloud by default. Dedicated instances in a specific region are available for enterprise deployments, which matters if you have data residency requirements. Contact us to discuss options.

​
9. Next steps

Integration paths

Autocapture vs. custom events.

Verify your integration

Confirm events are arriving before you ship.