Skip to main content
Flow2FA
Multi-channel OTP delivery

OTP verification without replacing your stack

Generate and validate SMS and email passcodes through documented REST endpoints, or route authentication traffic through an SMPP v3.4 bind.

Review your OTP setupHow the service works
Emerald smartphone displaying a six-digit verification code beside email message iconsSMS & email

01

REST or SMPP v3.4

Keep the integration path that fits your stack.

02

Flexible routing

Flow2FA routes, your providers or both.

What is Flow2FA?

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.

Flow2FA delivers and verifies OTPs over SMS and email, the channels documented in the public REST reference. Additional channels, including WhatsApp, depend on the setup provisioned for an account and are confirmed during setup.

Flow2FA is an OTP delivery and verification layer — not an identity provider, KYC service, fraud engine or replacement for phishing-resistant authentication.

Further detail: OTP API and service reference, API reference, provider evaluation guide, glossary and about Flow2FA.

Flow2FA at a glance

Category
B2B OTP delivery and verification service (2FA delivery layer)
Interfaces
Documented REST API, or SMPP v3.4 for existing messaging platforms.
Channels
SMS and email, the channels documented in the public REST reference. Additional channels, including WhatsApp, depend on the setup provisioned for an account and are confirmed during setup.
Provider model
Flow2FA-supplied routes, customer-owned providers and SMPP binds, or a combination of both.
Core functions
OTP generation, delivery attempts, configured retry and fallback, validation, and attempt and outcome tracking.
Service boundaries
Flow2FA is not an identity provider, identity-proofing or KYC service, fraud engine, passkey replacement or payment-network control, and it does not guarantee message delivery.
Operated by
Flowstates Inc.

Fit check

Is Flow2FA the right layer for your authentication flow?

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.

A good fit when

  • Your application, CRM, gateway or identity platform already creates the authentication event.
  • You need OTP generation, delivery attempts, configured retry/fallback and validation.
  • You operate across multiple countries, channels, providers or routes.
  • You want to retain an SMPP submit path, use a REST integration, or support both.
  • You want Flow2FA-supplied routes, customer-owned providers or a hybrid model.

Documented REST flow

What the integration actually looks like

  1. Generate the challenge

    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.

  2. Store the identifier

    Flow2FA returns otpId, destination, createdAt and expiresAt. You store otpId against your own login, transaction, registration or recovery record.

  3. Validate the code

    Your backend calls POST /otp/validate with the stored otpId and the otp value the user entered.

  4. Complete or reject the action

    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

Two integration paths, three delivery models

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.

REST API

  • Best for applications that can call the service directly.
  • Public surface: /otp/generate and /otp/validate.

SMPP v3.4

  • Best for organisations already sending authentication messages through a gateway, CRM or messaging platform.
  • Existing submit logic can often remain in place while routing changes behind it.

  • Flow2FA-supplied delivery

    Teams without suitable provider relationships, or teams that want fewer delivery integrations to run.

  • Customer-owned providers

    Teams with existing commercial relationships or market-specific routes they want to keep.

  • Hybrid by channel or market

    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

Choose channels by reach, assurance and operational reality

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.

  • SMS

    Broad handset compatibility and familiar OTP behaviour for most consumer flows.

    Documented public REST channel; may use customer or Flow2FA routes.

  • Email

    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.

  • WhatsApp

    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.

Routing hub cascading an OTP across SMS and email delivery lanes with fallback

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

Where OTP fits — and where it does not

  • A successfully entered code is evidence of access to a destination at that moment. It is not proof of real-world identity, transaction intent or legitimacy.
  • Manually entered OTPs are not phishing-resistant, because a code can be relayed by an attacker in real time.
  • NIST treats out-of-band authentication over the public telephone network, such as SMS or voice, as restricted, and recommends considering signals such as SIM change and number porting.
  • Higher-risk or privileged access should prefer phishing-resistant authenticators where that is practical.
  • The customer’s identity and risk system remains responsible for deciding when SMS, email, configured WhatsApp or a fallback path is appropriate, and for binding the challenge to the user, session and action.

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

Measure the outcome, not just the message

Delivery receipts describe network events. The commercial outcome is whether the user completes verification before the code expires.

  • 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.

  • Cost per completed verification

    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.

Use cases

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 cases
Illustration of an OTP code delivered to a phone, verified through a secure gateway

Review your current OTP flow

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.

Review your OTP setupTalk to sales