Changelog

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.