DLT registration & template filing — free with every plan

Two-factor authentication (2FA) API

Two endpoints instead of a subsystem: one issues a code, one verifies it. We hold the code, the attempt count and the expiry, so your application never stores or compares a secret — and the same code can go by SMS, voice call or WhatsApp.

Send + verify endpointsNo OTP in your databaseSMS / voice / WhatsAppBuilt-in rate limitingExportable audit log
🔐Two-factor authentication

Second-factor verification you do not have to build.

Writing your own OTP layer looks like an afternoon of work and turns into a quarter of maintenance. Code generation, expiry, retry limits, the race when a user requests a second code before the first expires, the abuse case where somebody loops your endpoint to bomb a stranger's phone, and a storage decision that a security reviewer will eventually ask you about. All of it is undifferentiated work that every product rebuilds identically.

With the 2FA API you call send with a number, and call verify with whatever the user typed. The code itself lives on our side with its expiry and attempt counter, so there is no secret in your database to leak and nothing to compare in your own code. If you would rather generate codes yourself, you still can — use the OTP SMS route directly and keep the logic in-house.

  • Send and verify endpoints — no OTP storage or comparison in your codebase.
  • Configurable code length, expiry and maximum attempts per application.
  • Multi-channel — the same code can go by SMS, voice call or WhatsApp.
  • Rate limiting and abuse protection to stop OTP-bombing of your users.
  • Audit log of every issue and verify event, exportable for compliance review.
How it works

From enquiry to first message, usually the same day.

Create an application

Each app gets its own key, code length, expiry, retry ceiling and channel order — so your web login and your delivery-partner app can behave differently.

Call send

One POST with the mobile number. We generate the code, pick the channel and return a reference. Nothing is stored on your side.

Call verify

POST the reference and whatever the user typed. You get a clean pass or fail, with the reason: wrong code, expired, or too many attempts.

Audit it later

Every issue and verify event is logged with a timestamp and channel, and exports for a security or regulatory review.

Side by side

Build it yourself versus the 2FA API

Build it yourself versus the 2FA API
ConcernRolling your own2FA API
Code generation and expiryYour code, your bugsHandled
Secret stored in your databaseYes — a review findingNo
Attempt limitingYou implement itBuilt in, per app
OTP-bombing protectionUsually missingBuilt in
Fallback to voice or WhatsAppA second integrationA config change
Audit trail for complianceYou build the logExportable
Where it is used

The jobs it actually gets hired for.

🔒Login and session security

A second factor on account access without building the plumbing for it.

  • Web and app login
  • Admin-panel access
  • Step-up for risky actions

💵Transaction confirmation

Verifying the human at the moment money or data moves.

  • Payouts and transfers
  • Bank-detail changes
  • High-value checkout

👤Profile and access changes

The events where an account takeover actually happens.

  • Mobile or email change
  • Password reset
  • New-device approval
☛

It bills like SMS, not like a subscription

There is no separate licence for the 2FA layer. You pay for the messages the API sends at your normal SMS, voice or WhatsApp rate — so if a user verifies on the first code, you paid for exactly one SMS.

FAQ

Two-factor (2FA), answered.

What is the difference between 2FA and OTP SMS?

OTP SMS is the delivery route: you generate a code and we deliver it fast. The 2FA API is the whole flow — we generate the code, hold it with its expiry and attempt counter, deliver it, and verify it when you pass back what the user typed. Use OTP SMS if you want to keep the logic; use 2FA if you would rather not write it.

Does the OTP get stored in my database?

No, and that is the main reason teams move to this API. The code lives on our side against a reference ID; your application stores the reference, never the secret, so there is nothing sensitive to leak from your own tables.

Can the same code be sent on WhatsApp or by voice call instead?

Yes. You set a channel order per application — for example WhatsApp first, SMS if the WhatsApp message is not delivered, voice call if the code is still not verified. Your API calls do not change when you reorder the channels.

How do you stop someone abusing the send endpoint?

Per-number and per-key rate limits, a cap on codes issued in a window, and an attempt ceiling before a reference is burned. Without those, an open OTP endpoint can be looped to flood a stranger's phone at your expense.

Enquiry & quote

Tell us what you need. We reply the same day.

Send your requirement and our team will set up a free test account with live credits, help you file your DLT header and templates, and share a written quote.

Send your requirement

We reply with a price, and set up free test credits so you can check delivery before you pay.

or

By submitting you agree to be contacted about your enquiry. We never sell or share your data — see our privacy policy.

Chat with us