Changelog

WhatsApp can now verify a user in one of three modes, and your account runs exactly one of them. Code back is the default and is the flow that already existed: the user opens a wa.me link, sends the prefilled message, and we reply with their code. Inbound approve keeps the link but drops the code: the user’s message approves the OTP by itself, and there is nothing to verify. Template drops the link: we push the code straight to the user, so WhatsApp behaves exactly like SMS.

Your code never needs the mode’s name. A new completion field on the send, resend, and status responses says how the OTP finishes: "code" means collect a code and call POST /otp/verify; "inbound" means show the link, then poll GET /otp/{otp_id} or take the otp.approved webhook, and never show a code input. Read it together with action_url and the three modes fall out of two fields. completion is frozen on the OTP when it is created, so switching your account’s mode never re-points a verification already in flight.

The docs now say what resend actually does around WhatsApp. Under Template it is a code channel like any other and a plain resend advances into and out of it. Under the two link modes WhatsApp works as the first channel only: a plain resend skips it anywhere else, and only an explicit resend {"channel":"whatsapp"} moves an OTP onto it, with the response carrying the link for your app to show. An OTP already on a link needs an explicit resend {"channel":"sms"} to move off it; a plain resend there re-returns the same link.

Code back stays on by default. To switch, email info@otp.com. The full guide, with a screenshot of what the user sees in each mode, is at WhatsApp verification.

Verification can now run on the device. The iOS (Otp), Android (com.otp:sdk-android), and React Native (@otp.com/sdk-react-native) SDKs present a screen, send the code, take the user’s input, and hand your app a short-lived verification_token. The floors are iOS 15 and Android API 26.

That token, not the screen’s own result, is the outcome. Your backend exchanges it at the new POST /verifications/exchange with your server key, and only that response names the recipient that was verified. A success read off a device you do not control is not evidence: the app authenticates with a publishable key (otp_pk_live_…) that is built to ship inside the binary and deliberately cannot read a recipient or exchange a verification.

The server SDKs make that call for you from 1.2.0. Install steps and a minimal end-to-end sample per platform are in Mobile SDKs, and the endpoint is documented at POST /verifications/exchange.

otp.com is out of preview and open to everyone. Create an account, generate a key on the API Keys screen, and send your first code from the quickstart in about five minutes.

What you get on day one:

• Four channels behind one call. SMS, WhatsApp, Telegram, and email. You pass a recipient, not a channel: your routing picks one, with per-country overrides and automatic fallback when the first attempt does not land.
• One verify step, every channel. POST /otp/verify closes the loop no matter how the code was delivered, WhatsApp included. The code is never returned by the API.
• A sandbox that costs nothing. A otp_test_… key runs the whole flow without sending a real message or charging anything. The accepted code is 123456.
• Typed clients and agent tools. Official SDKs for Node.js, Python, Go, and PHP, generated from the public OpenAPI spec, plus an MCP server so an AI agent can run verification itself.
• Signals you can build on. Webhooks for approvals and delivery outcomes, and IP-aware abuse protection when you pass client_ip.

Everything above is documented under Docs. If something is missing from the reference, that is a bug in the docs: tell us and we will fix it.

WhatsApp verification works like every other channel: the user enters a code and you call POST /otp/verify. The only difference is delivery. When your routing selects WhatsApp, POST /otp/send returns an action_url (a wa.me link) and the OTP stays pending. The user opens it and sends the prefilled message, we reply over WhatsApp with their code, and they enter it to verify, exactly as on SMS, email, or Telegram.

There is no per-channel branching: show a code input and call verify on every channel. The otp.approved webhook fires on approval if you prefer a push signal. If the user does not have WhatsApp, move the OTP onto SMS with a resend ({ "channel": "sms" }).

See Channels and routing.

This page now tracks notable updates to otp.com: new channels, API endpoints, SDK releases, and improvements to the docs and site.

Bookmark it or check back here to see what’s shipped. Each entry is tagged so you can tell new features from fixes at a glance.

Point any MCP client (Claude Desktop, Claude Code, Cursor, or your own agent) at @otp.com/mcp and it can send, verify, resend, and check one-time codes through your API key. There is no backend to run and no secret in the source: the key is supplied at runtime.

Each API action maps to one tool: send_otp, verify_otp, resend_otp, and get_otp_status. See the MCP docs to wire it up.

Typed client libraries are now available for Node.js (@otp.com/sdk-node), Python (otp-sdk), Go (github.com/otp-com/sdk-go), and PHP (otp-com/sdk-php).

They are generated from the public OpenAPI spec, so they stay in sync with the API and expose the same four actions: send, verify, resend, and status. Full setup and examples in the SDK docs.

resend now moves the code to the next channel in your routing order, so a delivery that stalls on one channel can complete on another without any change to your integration.

See how routing and fallback work in Channels and routing.

Create an otp_test_… key to run the full send, verify, resend, and status flow without sending real messages or spending credits. Swap in your otp_live_… key when you are ready to go live.

Details in the sandbox docs.