Generate and validate one-time passcodes through two documented REST endpoints, or route existing authentication traffic through an SMPP v3.4 bind. Your application or identity platform still decides when verification is required and whether the result completes the action.
Flow2FA is an OTP delivery and verification layer — not an identity provider, KYC service, fraud engine or replacement for phishing-resistant authentication.
Flow2FA is a business-to-business OTP delivery and verification service. It accepts authentication traffic through a documented REST API or SMPP v3.4, routes messages through Flow2FA-supplied paths, customer-owned providers, or both, and returns the verification result to the customer application.
Channel availability depends on the setup configured for each account. The current public REST reference documents SMS and email channel values, while configured Flow2FA setups may also include WhatsApp.
Further detail: OTP API and service reference, API reference, provider evaluation guide, glossary and about Flow2FA.
Fit check
Flow2FA is most useful when delivery operations, provider dependence or an existing messaging stack are the constraint. It is not a replacement for the system that decides who should be authenticated or what action should be approved.
Documented REST flow
Your backend calls POST /otp/generate with the documented fields: channel, provider, destination, type, length, expiresInSeconds and an optional templateId. The required provider value is the account-configured provider or delivery-profile value issued during onboarding for that channel; documentation examples are illustrative only.
Flow2FA returns otpId, destination, createdAt and expiresAt. You store otpId against your own login, transaction, registration or recovery record.
Your backend calls POST /otp/validate with the stored otpId and the otp value the user entered.
Flow2FA returns the validation result. Your application decides whether to complete the login, payment, recovery or access event.
Flow2FA does not interpret what the business action means, and it does not bind the challenge to your user, session or action automatically. That binding is created in your application when you store otpId against your own record.
Field-level detail is in the API reference, and the OTP API page explains the provider field, SMPP correlation and the operational controls you configure.
Integration and delivery model
Neither interface is universally better, and the provider model is not all-or-nothing. The decision depends on where authentication requests are created, where messaging correlation already lives, and which vendor contracts you want to keep.
Teams without suitable provider relationships, or teams that want fewer delivery integrations to run.
Teams with existing commercial relationships or market-specific routes they want to keep.
Preserving strong existing routes while reducing single-provider dependence.
Full detail on the OTP API page — the full REST and SMPP comparison, what each delivery model supplies and what you retain, the trade-offs, and how retry and fallback policy is applied.
Channels
A second channel is not automatically a security upgrade. Each channel has different enrolment, deliverability and account-compromise risks, and a fallback path should be approved for the specific action being protected.
Broad handset compatibility and familiar OTP behaviour for most consumer flows.
Documented public REST channel; may use customer or Flow2FA routes.
Useful for email-address confirmation, activation, selected recovery or fallback where you accept mailbox access as the signal.
Documented public REST channel; configuration and sender setup apply.
A data-based destination that may provide recognisable business presentation where the user is enrolled and the account is configured.
May be included in configured Flow2FA setups; not currently a documented public REST channel value.
Full detail on the OTP API page — the constraints to plan for on each channel, the configured channel-order and fallback policy, and what happens when a delivery path degrades.
Security boundaries
Full detail on the OTP API page — the controls to require from any OTP provider, the split between the Flow2FA delivery layer and your application, and the primary NIST and OWASP sources.
Evidence
Delivery receipts describe network events. The commercial outcome is whether the user completes verification before the code expires.
Completed validations divided by generated challenges.
The core outcome: whether users actually finish the flow you paid to deliver.
Completion without a resend or a fallback channel.
Exposes friction that a headline delivery figure hides.
Primary, retry and fallback cost divided by completed validations.
A fairer commercial comparison than price per submitted message.
The complete measurement set and the caveat about which reporting fields exist on each integration path are on the OTP API page. The provider evaluation guide explains how to request that evidence during a pilot and how to compare cost per completed verification.
The right controls differ between login, transaction approval, onboarding, recovery and enterprise access. Each page explains what the OTP proves, the failure modes and the controls the customer application still owns.
View all use casesLogin authentication
Secure logins with two-factor and multi-factor authentication.
Explore use caseTransaction verification
Confirm wire transfers and high-value actions in real time.
Explore use caseUser onboarding
Confirm access to a phone number, WhatsApp account or email during registration.
Explore use caseAccount recovery
Enable secure password resets with single-use passcodes.
Explore use caseE-commerce
Confirm high-value orders and protect stored payment details.
Explore use caseEnterprise access
Secure access for remote teams via internal SMPP binds.
Explore use case
Bring your monthly volumes by country, current providers or SMPP binds, code lifetime, resend rules, fallback policy and any delivery or verification data you already have. We’ll map the single points of failure, integration options and the evidence required before changing the flow.
