Which product to use, and when

SignOps has five products. Each does one job well, and most apps use two or three of them together. This page matches them to the jobs, so you set up only what you need.

The five products in one line each

Product	What the user does	What your app needs
Push	Gets a notification on Android, iOS or the web	Firebase or an Apple key, and the device token
Email OTP	Types a 6-digit code from an email, or taps a link	Your own sending domain, with five DNS records
Passkeys	Signs in with a fingerprint, face or screen lock	Your domain, and the browser script or the phone SDK
Authenticator	Types a code from Google Authenticator or a similar app	Nothing in the app: a page with a QR code
Approve	Taps the number on a phone that is already signed in	The phone SDK in your app, and push set up

Match the job to the product

The job	Use	Why
Confirm an email at sign-up	Email OTP	The user has nothing else set up yet
Sign in without a password	Passkeys, with Email OTP or a magic link as the fallback	A passkey cannot be phished; the email covers new devices
A second step after the password	Passkeys or Authenticator	Both cost less than SMS and need no DLT registration
A second step for users who refuse apps	Email OTP	Everyone has an email inbox
Approve a sign-in on a new laptop	Approve	The user’s phone shows the request and a number to match
Confirm a payment, a payout or a password change	Approve, or Passkeys	The user confirms on a device you already trust
Recover an account after a lost phone	Email OTP, then authenticator backup codes	Approve and device passkeys go with the phone
Order updates, reminders, offers	Push	Free per message, sent to a user, a topic or everyone
Tell users about a new sign-in	Push	A message to their own devices (new-login alerts on Starter and Pro)

Recipes for common apps

A website with email and password today. Add Email OTP for sign-up and password reset. Offer a passkey after the next sign-in (“Sign in faster next time”). Offer the authenticator app on the security settings page for users who want a second step.

A mobile app with phone-number login by SMS. Keep SMS for the very first sign-in if you must, and move every later sign-in to a passkey in the app. Use Approve when the same user signs in on the website: their phone gets the request. Use Push for order and account updates. Every sign-in that moves off SMS saves the SMS price.

A fintech or payments app. Passkeys or Approve on every sign-in, Approve for each payment above your own limit, and the authenticator app with backup codes as the fallback. The RBI’s 2025 directions accept these as factors other than SMS OTP.

A B2B dashboard. Email OTP or a magic link to sign in, the authenticator app as the second step (admins expect it), and passkeys for users who want them.

The order to set things up

1. Get your keys. Sign up. Every app has a test key (sk_test_) that works at once and a live key (sk_live_) that works after your account is approved. Secret keys stay on your server. The publishable key (pk_live_) is the only one that goes in an app or a web page.
2. Pick your first product from the table above and follow its guide:
   • Push on Android, on iOS, on the web, or in React Native, Expo and Flutter
   • Email OTP and magic links
   • Passkeys on your website, then in your Android and iOS apps
   • Authenticator app codes
   • Approve (set up push first: the request reaches the phone as a push)
3. Add a webhook under Webhooks in the dashboard, so your server hears about failed pushes, approvals, locks and bounces without asking.
4. Test with the test key, then swap in the live key. Test keys reach only devices and addresses you mark as test, and nothing they do is billed.

One user id everywhere

Every product works under your own user id: the one your database already has, any string up to 128 characters. SignOps never makes one for you. That is what lets a user’s devices, passkeys, authenticator and approvals sit together, and what Delete, export and consent erase in one call when the user asks.