Running as the tenant's app

What a host app built on the SenseCrypt Mobile SDK must declare when it is the app a tenant's users install — app links on the tenant's app-link host, the custom URL scheme, attestation identity, and push through the tenant's own Firebase project.

An app built on the SDK is usually the app the tenant's users install in place of the SenseCrypt Authenticator. The server then verifies your app: attestation is checked against your identity, pushes go through your Firebase project, and sign-in links are issued on a host your app is verified for. The tenant registers all of that once on the console's Mobile App page, described in Ship your own Authenticator app. This page is the host-app half: what your project declares so the two sides match.

Until the tenant registers your app, the server expects the stock Authenticator. Under enforce attestation your device flows fail with attestationFailed, pushes are not delivered to your tokens, and sign-in links open the stock app. Register first, in Audit mode.

App links

Sign-in links arrive as universal links (iOS) and App Links (Android) on the tenant's app-link host, which defaults to the tenant's own host, https://<slug>.sensecrypt.com. The host publishes /.well-known/apple-app-site-association and /.well-known/assetlinks.json from the registration, so there is nothing for you to host. Your app claims the host:

iOS: the associated-domains entitlement applinks:<app-link host>, on the app target.
Android: an autoVerify intent filter for https://<app-link host>/v1/link/*.

The SDK has no setting for the host. Your app receives the link from the OS and passes its bytes to a flow with submitLinkPayload. A pushed link can be a sign-in or a Face PKI ceremony; see the hand-off rule.

If the tenant later picks a verified custom domain as its app-link host, your app must claim that host instead and ship a new build.

Custom URL scheme

Sign-in pages also offer tap-to-open links of the form <scheme>://link/…, where the scheme is the one the tenant registered. Declare the same scheme in your Android intent filter and iOS URL Types. Do not use sensecrypt: it collides with the official app on a phone that has both, and the console refuses it.

App attestation

The server checks every device request against the identity the tenant registered: the Android package name and signing-certificate fingerprints, and the iOS team ID and bundle ID.

Android: pass your Google Cloud project number as playIntegrityCloudProjectNumber to open() (see Initialization). The project must be the one linked in Play Console. 0 disables Play Integrity in the SDK; the server then treats the request as unattested.
iOS: enable the App Attest capability. Store builds use the production environment. A development-signed build attests against Apple's sandbox, which the server accepts only while the tenant has turned off Require production App Attest environment.

What happens when attestation is unavailable or fails depends on the tenant's mode:

Tenant mode	Simulator or emulator	Genuine device, identity mismatch
`off`	Flows work.	Flows work.
`audit`	Flows work; the server logs the verdict.	Flows work; the server logs the mismatch.
`enforce`	Link submission fails with `attestationFailed`.	Link submission fails with `attestationFailed`.

attestationFailed is terminal for that link. Re-aiming the camera cannot fix it. See Errors.

Push notifications

CIBA sign-in requests and Face PKI ceremonies reach the phone by push. Pushes for a tenant on its own app are sent through the tenant's Firebase project, using the service-account key the tenant uploaded on the console. Nothing is ever sent through SenseCrypt's project for such a tenant; without an uploaded key, pushes are skipped and users rely on the emailed link.

Your app's side is unchanged from Push notifications: obtain an FCM registration token from Firebase Messaging configured with your google-services.json or GoogleService-Info.plist, and hand it to the SDK with updatePushToken. On iOS, push rides FCM too; upload your APNs authentication key to Firebase rather than to SenseCrypt.

Names, store links and branding

The appLabel in AuthenticatorConfig is local to the device: the SDK stores it and returns it from appLabel(), and nothing on the server reads it. What sign-in pages and emails call your app is the app name the tenant registered.
The sign-in page's "Get the app" buttons link to the App Store and Play Store URLs the tenant registered. Register the internal-test link until the listing is public.
End-user emails for a tenant on its own app carry the application's Branding instead of SenseCrypt's.
The relying-party branding your flows receive in awaitingFaceCapture.branding is unaffected; it comes from the application the user is signing in to.

Checklist

Associated domains / App Links filter claims the tenant's app-link host, with /v1/link/*.
Custom URL scheme matches the console, and is not sensecrypt.
playIntegrityCloudProjectNumber is your project number; App Attest capability on; production environment for store builds.
Firebase Messaging configured from your own Firebase project; APNs key uploaded to Firebase.
The tenant's Mobile App page lists your package name, fingerprints, team ID and bundle ID, has your service-account key, and starts in Audit.

Ship your own Authenticator app — the console registration, step by step.
Initialization — open() and playIntegrityCloudProjectNumber.
Push notifications — staging and uploading the FCM token.
Login flow — submitting the link your app receives.