OTP and 2FA service
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.
Two integration paths exist. The documented REST API is a two-endpoint surface for applications that can call Flow2FA directly. SMPP v3.4 lets an existing messaging platform keep its submit path and bind to Flow2FA instead of, or alongside, its current routes.
This page is the definitive service reference: what the service does, how each path works, which delivery models are available, which channels apply, what happens when delivery degrades, which controls you configure and what to measure. If you are still deciding whether OTP is the right control for your flow, start with the fit check on the homepage.
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.
An OTP service creates a short-lived code, sends it to a destination already recorded for the user, and checks the value the user types back. The signal it produces is possession: at this moment, someone controls that number, WhatsApp account or mailbox.
Everything of consequence sits around that signal — when a challenge is raised, which channel carries it, how long the code lives, how many attempts are permitted, and what your application does with the result. Those policies stay with you; Flow2FA carries out the generation, delivery and validation.
Unfamiliar terminology is defined in the OTP and 2FA glossary.
POST /otp/generate creates a code, sends it over the configured channel, and returns an otpId.POST /otp/validate accepts the otpId plus the otp the user entered and returns the result. Your application decides what to do with it.The generate request requires a provider value: the account-configured provider or delivery-profile value issued during onboarding for that channel. Credentials stay server-side, documentation examples are illustrative only, and whether a permitted value maps to one underlying vendor or to an account-specific managed routing arrangement is confirmed during setup.
Field-level detail, authentication and error codes are in the API reference.
If authentication messages already leave through a messaging platform, gateway or CRM, that submit path can often be retained. Flow2FA accepts an SMPP v3.4 bind, so the systems that create authentication requests do not have to change shape.
On this path, existing identifiers and operational correlation stay in your messaging platform, subject to your integration design. The validation path should be agreed during integration; the public REST reference documents /otp/validate separately.
Flow2FA can supply the delivery routes, use the vendors and binds you already contract, or run a combination — configured per channel and per market.
Ordering is a policy decision rather than a fixed cascade. Channel and route preference is configured from your own policy, observed performance in each market and the commercial arrangements you hold, with fallback rules defined alongside it.
| Model | What Flow2FA supplies | What you retain | Best suited to | Main trade-off |
|---|---|---|---|---|
| Flow2FA-supplied delivery | Configured messaging routes, with Flow2FA operating the delivery layer. | Authentication policy, user/session/action binding and the application decision on the result. | Teams without suitable provider relationships, or teams that want fewer delivery integrations to run. | Channel, market and commercial terms must be agreed for the configured service. |
| Customer-owned providers | Routing and workflow around approved customer providers or SMPP binds. | Your vendor contracts, sender registrations and the connectivity you supply. | Teams with existing commercial relationships or market-specific routes they want to keep. | Route quality and third-party provider performance remain part of the shared operating model. |
| Hybrid by channel or market | Flow2FA and customer-supplied routes combined according to the configured account policy. | Selected providers, while Flow2FA fills gaps or supplies other routes. | Preserving strong existing routes while reducing single-provider dependence. | More configuration and governance than a single-provider setup. |
Not all traffic is alike. Authentication messages have a narrow window to arrive before the code expires and the user abandons the flow, whereas bulk notifications can wait a little longer. Flow2FA keeps these workloads apart on its managed routes so that an OTP is not queued behind a large marketing send.
Dedicated OTP SMS routes. Short-code authentication SMS runs on dedicated routes separated from bulk and marketing traffic. Separation keeps authentication messages off shared queues, reduces exposure to throughput contention and carrier-level throttling, and helps codes arrive within the short validity window the flow depends on. The routes and short codes used for a given account are confirmed during onboarding and may vary by market.
Prioritised email channels. Authentication email is sent through prioritised sending channels with dedicated throughput and reputation monitoring, so verification mail is not held behind a batch of newsletters. Dedicated IP and pool configuration, where included for an account, keeps the sending reputation of OTP mail distinct from bulk email.
The benefit is practical: lower latency for time-sensitive challenges, fewer time-outs and resends, and a verification flow that is not at the mercy of unrelated traffic peaks. Whether dedicated routes, shared routes or a mix applies to your account is configured per channel and per market during setup, and routing can be tuned as volume and destinations change.
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.
| Channel | Where it can fit | Constraints to plan for | Flow2FA status |
|---|---|---|---|
| SMS | Broad handset compatibility and familiar OTP behaviour for most consumer flows. | Carrier filtering, route quality, roaming, sender-registration requirements, SIM-swap and number-porting exposure, and real-time phishing. SMS OTP is not phishing-resistant. | 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. | Mailbox compromise, forwarding, spam filtering, latency, and the possibility that using it as fallback lowers assurance. | 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. | Requires an eligible or enrolled destination, internet access, approved sender/template setup and customer-specific configuration. Manually entered codes remain non-phishing-resistant. | May be included in configured Flow2FA setups; not currently a documented public REST channel value. |
Flow2FA applies the channel order and fallback policy configured for the account. The customer decides whether a fallback channel provides enough assurance for the protected action.
A provider accepting an API request is not the same as a user completing verification.
Fallback can change assurance as well as delivery. A move from one channel to another should be explicitly approved for the use case and recorded, not treated as a universal default.
This separation is intentional: Flow2FA operates delivery and verification; it does not make identity or transaction-risk decisions for the customer.
Whether OTP suits your flow at all — and whether a different product would serve you better — is covered by the fit check on the homepage. These are the service boundaries that hold in every configuration.
These are controls to require and verify with any OTP provider, including Flow2FA, during security review. They are buyer requirements rather than claims about implementation internals.
The summary above is a paraphrase. Consult the linked sources for the current normative and recommended detail.
The assurance limits of OTP as a control are summarised in the security boundaries on the homepage.
Measure completed verification rather than accepted API calls, and read cost per completed verification rather than cost per message.
| Metric | What it tells you | Why it matters |
|---|---|---|
| Verification completion rate | Completed validations divided by generated challenges. | The core outcome: whether users actually finish the flow you paid to deliver. |
| First-attempt completion rate | Completion without a resend or a fallback channel. | Exposes friction that a headline delivery figure hides. |
| Request-to-delivery latency at p50 and p95 | Normal and tail delay between request and delivery. | Late codes cause abandonment and stale, expired codes. |
| Resend rate | The percentage of requests that need another code. | An early warning of delivery or user-experience problems. |
| Completion by country, operator, channel and route | Where completion differs across the traffic mix. | Localises degradation that aggregate figures conceal. |
| Delivery-to-verification gap | The difference between reported delivery and completed validation. | Shows why a delivery receipt is not proof of a successful verification. |
| Cost per completed verification | Primary, retry and fallback cost divided by completed validations. | A fairer commercial comparison than price per submitted message. |
Confirm the exact reporting fields, breakdowns and exports available for your configured account before contracting.
How to request this evidence during a pilotFlow2FA pricing should be assessed against the countries, channels, volumes and provider model configured for the account. Request a worked example against your own traffic rather than comparing a single headline message price.
An OTP service generates a short-lived, single-use code, delivers it to a destination already on file for the user, and then checks the code the user enters. It confirms current control of that phone number, WhatsApp account or mailbox — not who the person is.
Both roles are available. Flow2FA exposes an OTP API and can also carry the messages over its own routes. Customers who already contract providers can keep them, and the two models can be mixed per channel or market.
Yes. Flow2FA can route through customer-owned providers and SMPP binds, through Flow2FA-supplied routes, or through a combination, depending on the setup configured for the account.
No. Flow2FA delivers and validates codes. Your identity provider still owns accounts and sessions, and your fraud tooling still owns risk decisions.
No. A receipt indicates that a network accepted or reported the message. Verification is only complete when a code is validated and your application records the outcome.
No. A manually entered code can be relayed to an attacker in real time. OTP raises the cost of account takeover but is not a phishing-resistant authenticator.
The current public REST reference documents SMS and email channel values. Configured Flow2FA setups may also include WhatsApp.
Neither is universally better. REST suits applications that can call two endpoints directly. SMPP v3.4 suits teams with an existing messaging platform whose submit path they would rather retain.
Secure logins with two-factor and multi-factor authentication.
Confirm wire transfers and high-value actions in real time.
Confirm access to a phone number, WhatsApp account or email during registration.
Enable secure password resets with single-use passcodes.
Confirm high-value orders and protect stored payment details.
Secure access for remote teams via internal SMPP binds.
Comparing providers? The buyer guide sets out evaluation criteria and evidence to request. Background on the operating entity is on the about page, and every flow is listed on the use-case hub.
Share the markets, channels and providers you use today, and we will walk through how a REST or SMPP configuration would be set up.