Secure OTP & 2FA API
One OTP API for two factor authentication, passwordless login and user verification over SMS, WhatsApp, Telegram and Email. Fallback, webhooks, per-country routing and an analytics dashboard are part of the OTP service, not add-ons.
send
POST /otp/send
{ "recipient": "+14155552671" }verify
POST /otp/verify
{ "otp_id": "9f3c1b2a-…", "code": "123456" }Two calls. Every channel, every use case on this page, runs on them.
Explore otp.com Features
Five capabilities covering the whole verification path: getting the code delivered, wiring the result into your backend, tuning delivery per market, and seeing what happened.
- 01
Automatic Fallback
One resend call moves the same verification to the next channel. You write no retry logic.
Read more - 02
Multiple APIs and Webhooks
A key per app, sandbox or live, each with its own webhook endpoint and signing secret.
Read more - 03
MCP Integration
Send, verify, resend and check status as agent tools over the Model Context Protocol.
Read more - 04
Country-Based Channel Routing
A default channel order, overridden per country where another channel delivers better.
Read more - 05
OTP Analytics Dashboard
Volume, delivery, cost and channel mix per country, plus fraud attempts blocked.
Read more
Automatic Fallback
A verification is a chain, not one delivery attempt. If a channel does not get the code through, or the user never types it, a single resend call advances the same OTP to the next channel in your order and returns the new channel.
You implement none of that. No retry queue, no per-channel bookkeeping, no second verification to reconcile: the otp_id never changes, so the code the user finally receives verifies through the call you already wrote.
WhatsApp is the one channel with a different shape, since its flow starts with the user opening a wa.me link. It takes part only as a first channel. For a user who turns out not to have WhatsApp, one resend naming sms moves that same pending verification across.
your channel order
- 1
SMS - 2
WhatsApp - 3
Telegram - 4
Email
resend response
{
"otp_id": "9f3c1b2a-…",
"status": "pending",
"channel": "sms"
}Same otp_id, new channel.
Multiple APIs and Webhooks
Keys are created per app, in one of two environments. A otp_test_… key runs in the sandbox, where nothing is delivered, nothing is charged and the accepted code is always 123456. A otp_live_… key sends real codes and bills per verification sent.
So staging and production never share credentials, and a key can be revoked on its own. Each app carries its own webhook endpoint and signing secret, which is what lets separate products report to separate backends.
Every event arrives in one envelope with an HMAC signature, so a single handler covers all four and you can prove it came from us. It is the push alternative to polling status.
events
| otp.approved | Verified with a correct code |
|---|---|
| otp.failed | Attempts exhausted, no correct code |
| delivery.delivered | Message reached the recipient |
| delivery.failed | Message failed to deliver |
payload
{
"id": "evt_…",
"type": "otp.approved",
"payload": { "otp_id": "…", "status": "approved" }
}Connect AI Tools with MCP
The otp.com MCP server exposes verification as tools an AI agent can call, over the Model Context Protocol. Point an MCP client at it, Claude Desktop, Claude Code, Cursor or an agent of your own, and the assistant gets the same four actions as the REST authentication API.
That covers two jobs. An agent that needs to verify a real user can do it with no backend of yours in the loop. And an assistant writing your integration can test it as it goes against a sandbox key, instead of guessing at the request shape.
The server is open source, and llms.txt gives any model a machine-readable map of the API.
agent tools
| send_otp | recipient |
|---|---|
| verify_otp | otp_id, code |
| resend_otp | otp_id, channel? |
| get_otp_status | otp_id |
One tool per API action. The agent never sees a channel: routing still picks it.
Country-Based Channel Routing
You never name a channel on a send. Routing decides it from the recipient, your default channel order, and any per-country overrides. An email address is emailed; a phone number walks your order.
The overrides are the point. Delivery is not uniform across markets, and SMS is the only channel priced per country. Where it is expensive or unreliable, another channel can go first for that country while the rest of the world keeps your default.
Because it is account configuration and not a request parameter, retuning a market ships without a code change or a release on your side.
where an override pays
| country | sms | |
|---|---|---|
| Comoros | $0.4238 | $0.0012 |
| Central African Republic | $0.3732 | $0.0012 |
| Madagascar | $0.3726 | $0.0012 |
| Ecuador | $0.3240 | $0.0012 |
Published rates, per verification. WhatsApp, Telegram and Email are flat worldwide; only SMS varies by destination.
OTP Analytics Dashboard
What actually happened, over a date range you choose, and exportable. The overview counts every verification and what it cost.
-
Total OTP Sent
per period
-
Verified
with auth rate
-
Delivery Rate
all channels
-
Total Spent
per period
-
Fraud Blocked
attempts stopped
-
Unique Recipients
new users
per country
Volume, delivery rate, cost and channel split for each market, with an average cost per verification. This is what tells you whether a routing override paid off.
per channel
How the mix actually fell out across SMS, WhatsApp, Telegram and Email, next to a live feed of recent verifications and their state.
fraud prevention
Attempts blocked, how many were stopped automatically, the spend that saved, and which countries the attempts came from.
Built for Authentication and 2FA
The same two calls cover every place a one-time password does real work, from passwordless authentication to a second factor behind a password you already have.
Login OTP
The code is the login. A phone number or email in, a passcode back, and the user is in. Nothing to remember, nothing for you to store or reset.
Two factor authentication
The second factor behind an existing password. A delivered code works for every user, including the ones who never enrolled an authenticator app.
Multi factor authentication
One factor inside a broader MFA policy. A verification is a self-contained send-then-verify pair, not a session, so it drops into an existing flow.
User verification
Proof that a signup controls the contact detail they gave you. Fake accounts and mistyped numbers stop before they reach your database.
All of it on a single one-time password API, with public per-verification pricing and no monthly minimum: enough to price otp.com against your current OTP provider before you move any traffic. The quickstart sends a first code in the sandbox in about ten minutes, and the FAQ covers cost and delivery.
Ship verification
with one prompt.
$3 free credits. No credit card. No sales call.
Your first OTP in 10 minutes.
