Skip to main content
Our Frontend SDKs are available for Android, iOS, Web, React Native and Flutter. They enable you to:
  1. Collect device signals to strengthen verification and reduce fraud.
  2. Perform silent verification to verify phone numbers without asking users to enter a code.
The Frontend SDKs currently can integrate with the Verify and Watch APIs.
SDK keys are publishable, client-side keys: safe to expose. Unlike your backend API key, the SDK key is designed to be embedded in client applications. It is expected to be visible in your browser JavaScript bundle, page source, or mobile app binary, and it is safe to keep in front-end deployment config such as CI/CD pipelines and Helm values.
Use a separate SDK key for each platform. When generating an SDK key in the dashboard, select the device platform (Android, Apple, Web, etc.) that matches your intended use case. This prevents cross-platform misuse and lets you rotate or revoke a single platform’s key independently. See Enforcing SDK signals.

​
How device signal collection works

1

Capture device signals

The Frontend SDK collects device signals and dispatches them to Prelude.
2

Dispatch ID creation

Prelude generates a Dispatch ID from those signals and returns it to the SDK.
3

Dispatch ID usage

Forward the Dispatch ID to your backend and include it in requests to Prelude’s Verify or Watch APIs.

​
Enforcing SDK signals

By default, a Dispatch ID is optional: requests without one are still processed, just without the extra device signals. Enforcement makes those signals a requirement, so a verification can only be started from a device that ran your SDK. Enforcement is configured per platform on the Verify API > Configure > SDK Signature page of the Prelude dashboard, and applies to the Create verification endpoint. Apple, Android, Web, and Unknown are enforced independently. Once a platform is enforced, verifications attributed to it are blocked when the SDK signals are missing, invalid, or expired. A blocked verification is returned with "status": "blocked" and one of the following reasons:

​
Platform attribution and the Unknown platform

A request is attributed to a platform using the dispatched signals, falling back to the signals.device_platform field of the verification request. iOS, iPadOS, and tvOS all count as Apple, and requests we can’t attribute to Apple, Android, or Web land in the Unknown bucket. Because a request with no Dispatch ID and no signals.device_platform is Unknown, enforcing only Apple, Android, and Web leaves a bypass open: an attacker can omit both.

​
Rolling out enforcement

1

Ship the SDK

Integrate the Frontend SDK on every platform you support.
2

Check your coverage

The SDK Signature page shows the share of signed requests per platform over the last 30 days. Wait until it is close to 100%: anything unsigned at that point is what enforcement would block, including traffic from older app versions still in the wild.
3

Enforce, one platform at a time

Turn enforcement on per platform, then finish with Unknown to close the bypass above. Enforcement is reversible at any time.

​
Learn more about each platform’s SDK

Web SDK

Learn how to integrate the Web SDK into your application.

Android SDK

Learn how to integrate the Android SDK into your application.

iOS SDK

Learn how to integrate the iOS SDK into your application.

React Native SDK

Learn how to integrate the React Native SDK into your application.

Flutter SDK

Learn how to integrate the Flutter SDK into your application.