DEV Community: Raya

Phone verification on a free RapidAPI key: WhatsApp first, SMS when it fails

Raya — Thu, 24 Sep 2026 03:44:08 +0000

Outside the US, a verification text is often the most expensive way to send a code, and in many countries WhatsApp reaches the same people for less. So it's worth trying WhatsApp first.

This post builds that in about 40 lines of Node: send the code on WhatsApp, watch for a delivery failure for a few seconds, and fall back to SMS only when WhatsApp can't reach the number. Checking the code works the same either way.

I work on MyOTP.App, so the example uses our API. It's on RapidAPI with a free plan, 100 credits a month and no card, which is enough to follow along.

Get a key

Subscribe to the Basic plan on the MyOTP.App listing. RapidAPI gives you a key for the x-rapidapi-key header.

Keep it on your server. A key in browser JavaScript is a key anyone can copy, and your credits go with it.

Send a code

curl -X POST https://myotp-app-2fa-sms.p.rapidapi.com/generate_otp \
  -H "x-rapidapi-key: YOUR_KEY" -H "x-rapidapi-host: myotp-app-2fa-sms.p.rapidapi.com" \
  -H "Content-Type: application/json" \
  -d '{"phone_number": "14155550123", "channel": "sms"}'

Use your own number. The phone number is digits only, country code first, no plus sign. The answer:

{
  "message_id": "429a1de7-a3a5-4148-ae14-56cbcdbc2772",
  "status": "accepted",
  "message": "OTP sent",
  "date_sent": "2026-09-23T01:33:12.402113",
  "expires_at": "2026-09-23T01:38:12.402113",
  "cost": 1.0
}

Times are UTC with no offset, so add a Z before you parse them in JavaScript. cost is the credits the send used, counted when the send is accepted. The code is 6 digits and lives 5 minutes unless you pass otp_length (3 to 8) or otp_validity (30 to 14400 seconds).

Check it

curl -X POST https://myotp-app-2fa-sms.p.rapidapi.com/verify_otp \
  -H "x-rapidapi-key: YOUR_KEY" -H "x-rapidapi-host: myotp-app-2fa-sms.p.rapidapi.com" \
  -H "Content-Type: application/json" \
  -d '{"message_id": "429a1de7-a3a5-4148-ae14-56cbcdbc2772", "otp": "123456"}'

{"status": "success", "message": "OTP verified"}
{"status": "failed", "reason": "invalid", "message": "OTP does not match"}

A failed check says why in reason: invalid, expired or not found. Checks don't use credits. A code that passed is deleted, so checking it a second time answers not found.

WhatsApp first, SMS if it fails

When a number can't receive WhatsApp, we hear about it fast. In our logs that failure usually comes back within 2 to 3 seconds. So the plan is: send on WhatsApp, read the status for about 10 seconds, and switch to SMS only on a failure.

Node 18 or later, no dependencies:

const HOST = "myotp-app-2fa-sms.p.rapidapi.com"

async function call(path, body) {
  const res = await fetch(`https://${HOST}${path}`, {
    method: "POST",
    headers: {
      "x-rapidapi-key": process.env.RAPIDAPI_KEY,
      "x-rapidapi-host": HOST,
      "Content-Type": "application/json",
    },
    body: JSON.stringify(body),
  })
  const data = await res.json().catch(() => ({}))
  if (!res.ok) throw new Error(`${res.status}: ${data.error?.message ?? data.message}`)
  return data
}

const sleep = (ms) => new Promise((r) => setTimeout(r, ms))

// Returns the message_id to verify against.
export async function sendCode(phone) {
  const wa = await call("/generate_otp", { phone_number: phone, channel: "whatsapp" })

  for (let i = 0; i < 5; i++) {
    await sleep(2000)
    const { DLR } = await call("/check_otp_status", { message_id: wa.message_id })
    if (String(DLR).startsWith("failed")) {
      const sms = await call("/generate_otp", {
        phone_number: phone,
        channel: "sms",
        force_send: "true",
      })
      return sms.message_id
    }
    if (DLR === "delivered" || DLR === "read") break
  }
  return wa.message_id
}

export async function checkCode(messageId, code) {
  const r = await call("/verify_otp", { message_id: messageId, otp: code })
  return r.status === "success"
}

Two details in there matter.

force_send: "true" on the SMS. The WhatsApp code is still live, and a second send to the same number without it answers 409.

The SMS is a new code with a new message_id. sendCode returns whichever one went out last, so that's the one you verify. Each attempt is charged when it's accepted, so a fallback costs the WhatsApp credit plus the SMS.

If WhatsApp only ever says sent, the loop gives up and keeps the WhatsApp code. That's on purpose. The code may still arrive, and sending a second one by SMS leaves your user holding two codes and guessing which. Give them a "Text me instead" button that makes the same force_send call.

On WhatsApp the code lives 5 or 10 minutes, set by the template. otp_validity doesn't change that, though it still has to be in range. template_order 12 is English with 5 minutes, 13 is English with 10. 14 and 15 are the same in Spanish.

Telegram is 1 credit everywhere and reaches numbers that have a Telegram account. Codes there are 4 to 8 digits and live up to an hour.

Before you ship

Cap wrong guesses in your app. Five tries, then ask the user to request a new code.
Put a cooldown on your resend button. Every send spends credits.
A resend while a code is still live needs force_send: "true", or it gets a 409. That includes the next send after a WhatsApp fallback.
/check_otp_status gives you delivery per message. For SMS that's the carrier's own word, such as DELIVRD or UNDELIV, and ATES while it's still on its way. For WhatsApp it moves through sent, delivered and read, or ends in a value starting with failed. Telegram can also report expired or revoked. Read it before you verify, since a verified code is gone.

What it costs

A code costs a different number of credits depending on where it goes and how it gets there:

Country	SMS	WhatsApp	Telegram
USA	1	1	1
Brazil	3	1	1
Mexico	8	1	1
India	9	3	1
Philippines	23	1	1
Nigeria	24	7	1

On the free plan that's 100 codes to the Philippines over WhatsApp, or 4 by SMS.

Plan	Price	Credits a month
Basic	Free	100
Pro	$25	1,000
Ultra	$100	5,000
Mega	$180	10,000

Every country and channel is on myotp.app/pricing. For more volume, write to sales@myotp.app.

If something in here doesn't match what you see, tell me in the comments. I read them.

Twilio Verify vs MyOTP for small apps: the honest version

Raya — Tue, 22 Sep 2026 19:56:58 +0000

I work at MyOTP.App, so this is a vendor writing about a competitor. I'll stick to things you can check yourself, and I'll say where Twilio is the better pick.

What each one is

Twilio Verify is a managed verification product on top of Twilio's messaging platform. It generates the code, sends it, checks it, and charges a per-verification fee on top of the message price. The same platform does voice, email, video and a lot more.

MyOTP.App does one thing: send and verify one-time codes over SMS, WhatsApp or Telegram. One API key, a per-message price, and that's the whole product.

Setup

Twilio Verify: an account SID, an auth token and a Verify service SID, then the start and check calls with Basic auth.

MyOTP: sign up, copy the key, allowlist your server's IP address, send. WhatsApp goes out from our own approved templates, so there's no Meta business verification on your side.

Neither setup is hard. Ours is smaller because the product is smaller.

Price

Verify's list price is $0.05 per successful verification plus the channel fee, and a US SMS is $0.0083. For a signup flow where each user verifies once, that's fine. For a login flow where users verify every session, the verification fee adds up faster than the messages do.

MyOTP charges per message, in credits, and the rate depends on the destination country and channel. Checking a code costs nothing. Telegram is one credit flat everywhere, and WhatsApp is often cheaper than SMS on the same route: India is 9 credits over SMS and 3 over WhatsApp. The full table is on the pricing page.

Delivery

Twilio is a large aggregator with good coverage almost everywhere. If your users are in the US or Western Europe, you won't have complaints.

We deliver SMS through BroadNet, the messaging group behind MyOTP. We reach 190+ countries on SMS, WhatsApp and Telegram, so check the price for yours before you commit. Where we don't have a price, the API answers 400 up front instead of accepting the message and failing later. On the Business plan you get delivery status per message, by polling or by webhook.

Where Twilio wins

You already use Twilio for voice or email and want one bill.
You need a HIPAA BAA or another compliance document we don't offer as a standard product.
You want SIM swap checks.

Where we win

You want verification without a per-verification fee.
Your users are global, in the Middle East, South Asia, Africa or Latin America, and you want to compare routes.
You want WhatsApp or Telegram as a channel without setting up Meta yourself.
An AI agent is building or running the app. Our MCP server is in the official registry, there's a CLI, and an agent can register and buy credits with USDC over HTTP 402 with no human in the loop.

Try it fairly

Run both for a week on real signups, half and half, and read your own delivery numbers. Switching is two API calls either way, and your numbers beat anything I write.

Better Auth phone numbers with a five-line OTP adapter

Raya — Wed, 16 Sep 2026 10:13:42 +0000

Better Auth's phoneNumber() plugin does the hard part of phone login. It generates the code, stores it, verifies it and manages the session. What it leaves to you is delivery: a sendOTP callback that you fill in. I work at MyOTP.App and we publish an adapter for that callback, so here's the whole setup.

Install

npm install @myotp/better-auth better-auth

Get a key at myotp.app/sign-up. 15 trial credits, no card.

Wire it

import { betterAuth } from "better-auth";
import { phoneNumber } from "better-auth/plugins";
import { myotpSendOtp } from "@myotp/better-auth";

export const auth = betterAuth({
  database: yourDatabase(),
  plugins: [
    phoneNumber({
      sendOTP: myotpSendOtp({ apiKey: process.env.MYOTP_API_KEY! }),
      otpLength: 6,
      expiresIn: 300,
    }),
  ],
});

That's it. Better Auth generates and verifies, MyOTP delivers.

Channel

myotpSendOtp({
  apiKey: process.env.MYOTP_API_KEY!,
  channel: "whatsapp",   // or "telegram", default "sms"
  brand: "Acme",         // optional sender name
})

To let the user choose at signup, wrap it: read the channel from your own request context and call myotpSendOtp with that value. The README has the wrapper.

Two things to know

Better Auth owns the code, so MyOTP never sees the verification. That means our delivery report tells you the message arrived, and Better Auth tells you whether the user typed it right. Two systems, two logs, and you'll want both when debugging a "code never came" ticket.

The key lives in your server environment. The adapter runs inside Better Auth on the server, so it never reaches the client bundle. Allowlist the server's public IP on the key in the MyOTP dashboard, or the first send from production comes back 403. That 403 means the allowlist, not a bad key.

Why not just call Twilio in the callback

You can. The callback is a function, it doesn't care. The reasons people pick us for it are setup, price outside the US, and WhatsApp and Telegram as channels without going through Meta's business verification. If your users are US-only and you already have a Twilio account, stay put.

Disclosure again: I work at MyOTP.App. The adapter is MIT, on npm and GitHub at brntech/myotp-agentkit.

Add phone verification to an Express app with Claude Code, with a real OTP behind it

Raya — Sun, 13 Sep 2026 13:09:11 +0000

Most apps that need phone verification rebuild the same five things: a form, a send, an expiry, a retry rule and a verify step. It's not interesting code but it's load bearing. Here's what happens when Claude Code has a real OTP API attached while it writes that code. I work at MyOTP.App, the API in question.

Setup

One line, once:

claude mcp add myotp -e MYOTP_API_KEY=your-key -- npx -y @myotp/mcp

The key comes from myotp.app/sign-up, 15 trial credits, no card. Allowlist your IP on the key, or * while developing.

The prompt

Add phone verification to my Express app. The user enters a phone number, gets a 6 digit code by SMS, types it in, and on success is marked verified. Use the MyOTP REST API from the server, never from the browser.

What came back

// routes/verify.js
const express = require("express");
const router = express.Router();
const pending = new Map(); // phone -> message_id

const API = "https://api.myotp.app";
const headers = {
  "Content-Type": "application/json",
  "X-API-Key": process.env.MYOTP_API_KEY,
};

// MyOTP wants digits only, country code first, no plus, no leading zero.
const clean = (p) => (p || "").replace(/\D/g, "").replace(/^0+/, "");

router.post("/send-code", async (req, res) => {
  const phone = clean(req.body.phone);
  if (!/^[1-9][0-9]{6,14}$/.test(phone)) {
    return res.status(400).json({ error: "invalid phone" });
  }
  const r = await fetch(`${API}/generate_otp`, {
    method: "POST", headers,
    body: JSON.stringify({ phone_number: phone, channel: "sms", otp_length: 6 }),
  });
  const data = await r.json();
  if (!r.ok) return res.status(r.status).json({ error: data.error?.message });
  pending.set(phone, data.message_id);
  res.json({ status: "sent", expires_at: data.expires_at });
});

router.post("/verify-code", async (req, res) => {
  const phone = clean(req.body.phone);
  const message_id = pending.get(phone);
  if (!message_id) return res.status(400).json({ error: "no code pending" });
  const r = await fetch(`${API}/verify_otp`, {
    method: "POST", headers,
    body: JSON.stringify({ phone_number: phone, message_id, otp: req.body.code }),
  });
  const data = await r.json();
  if (data.status !== "success") {
    return res.status(400).json({ error: data.reason }); // "invalid" | "expired" | "not found"
  }
  pending.delete(phone);
  res.json({ status: "verified" });
});

module.exports = router;

Plus the form and two lines in app.js. About a minute from prompt to a code arriving on my phone.

What it got right, and why

Three things in that code are the things people get wrong by hand.

The phone regex matches what the API enforces. phone_number must be digits only, 7 to 15 of them, no leading zero. The tool description carries that rule, so the model didn't guess.

Verification is keyed on message_id, not on the phone. Two codes in flight to the same number can't be confused.

The key never reaches the browser. The client posts a phone and later a code, nothing else.

The interesting part is that it tested the flow before writing it. With the MCP server attached, "send a code to my number" is a tool call. It sent one, read the response shape, then wrote code against what it had seen instead of what it remembered.

Channels

Change channel to whatsapp or telegram and nothing else moves. Worth doing where SMS is expensive or slow, which is most of South Asia, Africa and Latin America.

When not to do this

If your framework already owns phone auth, use its hook instead. Supabase has the Send SMS Hook, Better Auth has a sendOTP callback, and both take a MyOTP adapter without you writing the routes above. This pattern is for the plain Express or Fastify app that has nothing yet.

Disclosure again: I work at MyOTP.App. Prices and limits are on the site. If the code above breaks for you, tell me in the comments and I'll fix the post.

Phone verification in Flask and Django with one API key

Raya — Wed, 09 Sep 2026 05:35:58 +0000

Most "phone verification in Python" tutorials are four years old and assume a Twilio account. Here's the version with one API key and two HTTP calls. I work at MyOTP.App, the API used below, and the full Flask and Django examples are in the brntech/myotp-agentkit repo.

The two calls

Send:

import os, re, requests

API = "https://api.myotp.app"
HEADERS = {"X-API-Key": os.environ["MYOTP_API_KEY"]}

def clean(phone: str) -> str:
    # digits only, country code first, no plus, no leading zero
    return re.sub(r"\D", "", phone).lstrip("0")

def generate_otp(phone: str, channel: str = "sms") -> dict:
    r = requests.post(f"{API}/generate_otp", headers=HEADERS,
                      json={"phone_number": phone, "channel": channel, "otp_length": 6})
    r.raise_for_status()
    return r.json()   # {"message_id": "...", "status": "accepted", "expires_at": "...", "cost": 1.0}

Verify:

def verify_otp(phone: str, message_id: str, otp: str) -> dict:
    r = requests.post(f"{API}/verify_otp", headers=HEADERS,
                      json={"phone_number": phone, "message_id": message_id, "otp": otp})
    return r.json()   # {"status": "success"} or {"status": "failed", "reason": "invalid" | "expired" | "not found"}

Everything else is your framework's job: where to keep message_id between the two requests, and what to do on success.

Flask

Keep message_id in the signed session cookie. It's an opaque UUID and the cookie is tamper-proof, so that's enough for a single server.

@app.post("/send")
def send():
    phone = clean(request.form["phone"])
    result = generate_otp(phone, request.form.get("channel", "sms"))
    session["message_id"], session["phone"] = result["message_id"], phone
    return redirect(url_for("verify"))

@app.post("/verify")
def verify():
    result = verify_otp(session["phone"], session["message_id"], request.form["code"])
    if result["status"] != "success":
        return render_template("verify.html", error=result["reason"]), 400
    session.pop("message_id")
    return redirect(url_for("done"))

For more than one server, use flask-session or a database row instead of the cookie.

Django

Same shape, with the session backend you already have. Put the two functions in verification/services.py and the views become:

def send(request):
    phone = clean(request.POST["phone"])
    result = generate_otp(phone)
    request.session["otp"] = {"message_id": result["message_id"], "phone": phone}
    return redirect("verify")

def verify(request):
    pending = request.session.get("otp")
    result = verify_otp(pending["phone"], pending["message_id"], request.POST["code"])
    if result["status"] != "success":
        return render(request, "verify.html", {"error": result["reason"]}, status=400)
    del request.session["otp"]
    request.user.profile.phone_verified_at = timezone.now()
    request.user.profile.save()
    return redirect("done")

The three mistakes

Calling the API from the browser. The key would ship in your JavaScript. Both examples above run server side.

Verifying by phone number instead of message_id. Two codes in flight to one number and you'll accept the wrong one.

Forgetting the IP allowlist. A key made from your laptop is allowlisted to your laptop. The first send from the server comes back 403 with "Access from this IP not allowed". Add the server IP in the dashboard. It's not the key.

Channels

channel takes sms, whatsapp or telegram. Nothing else in the code changes. If your users are somewhere SMS is slow or expensive, that one string is the difference.

Disclosure again: I work at MyOTP.App. 15 trial credits on signup, no card, and the examples are MIT.

HTTP 402 explained for developers who don't care about crypto

Raya — Mon, 07 Sep 2026 22:11:00 +0000

Status code 402 has been in the HTTP spec since 1997 with the label "Payment Required" and no defined behaviour. It's finally getting one, and the reason is boring in a good way: software that runs without a person nearby needs a way to pay for things.

I work at MyOTP.App. We sell OTP delivery, and this year we started answering 402 to agents that run out of credits. Here's what that means with the crypto vocabulary taken out.

The problem it solves

An agent is building or running an app for someone. It needs to send a verification SMS. It has an API key with zero credits. Today the flow stops, a human is paged, they open a dashboard, enter a card, and the agent resumes an hour later. Every API that charges money has this cliff.

What a 402 flow looks like

The client calls the API. The server answers 402 with a header describing what it will accept: an amount, a currency, and one or more ways to pay. The client pays using one of them, gets a receipt, and repeats the request with the receipt attached. The server verifies the receipt and serves the request. No checkout page, no form, no session.

The protocol we use is Stripe's Machine Payments Protocol, and it's the "one or more ways" part that makes it usable outside crypto. Our 402 offers two:

A card, through a Stripe Link wallet the agent's owner authorised once. The agent presents a scoped, time-limited token, not the card number.
USDC, a dollar-pegged stablecoin, for agents that hold a wallet and no card.

The client picks whichever it has. The API doesn't care.

What ours looks like

POST https://api.myotp.app/v1/topup
Content-Type: application/json
{"credits": 100}

402 Payment Required
WWW-Authenticate: Payment ... (two offers: card via Stripe, USDC on Tempo)

Pay, retry with the receipt, get:

200 OK
{"credits_added": 100, "balance": 115, "amount_usd": "2.00"}

The numbers: $0.02 a credit, 25 credits minimum because that's Stripe's card floor, 50,000 maximum per call. Cards are capped at $100 per account per rolling day, and over that the 402 offers USDC only. That cap is the fraud control. Stolen cards get tested against APIs like ours, and a low daily ceiling makes us not worth the effort.

Why an agent should use it instead of asking a human

Because the human isn't there. That's the whole reason. The agent registers an account with one call, gets a key, and the first time it hits zero balance it gets a 402 and pays. Our MCP server exposes this as get_topup_quote and top_up_credits, and the CLI as myotp topup, so most agents never see the raw protocol.

What it isn't

It's not a subscription. Each 402 is one payment for one top-up. It's not a way to bypass Stripe's rules, since Stripe is the one processing the card. And it's not anonymous: the account behind the key has an email, and card top-ups need that email confirmed.

Should you add it to your API

If your API is called by software that runs unattended and your smallest sale is under a few dollars, yes, and it's a few hundred lines with Stripe's SDK. If your customers are humans with a dashboard, the checkout page you already have is fine.

Disclosure again: I work at MyOTP.App. The contract for our endpoint is public and the MCP server and CLI are open source at brntech/myotp-agentkit.

MCP for auth in 5 minutes: phone verification through your AI agent

Raya — Thu, 03 Sep 2026 22:14:48 +0000

Most AI coding tutorials stop at "ask the agent to write code". This one is about giving the agent a tool it can call, an MCP server, so it can send and verify one-time codes while you're still building. I work at MyOTP.App and this uses our server, so read it with that in mind.

If you're on Claude Code, Claude Desktop, Cursor, Codex or anything else that speaks MCP, this takes about five minutes.

Why bother

When you ask an agent to "add phone verification" with no tool attached, it writes code against an SDK it half remembers. Sometimes that SDK doesn't exist in the version it picked. You find out at runtime.

With the MCP server attached, "send a code to my number" is a tool call. The agent sends a real message, you get a real SMS, and only then do you ask it to write the integration. The code comes after the proof.

Setup

There's nothing to install. npx fetches it on demand.

Get an API key at myotp.app/sign-up. New accounts get 15 trial credits, no card. Add your IP to the key's allowlist, or use * while you're developing locally.
Add the server to your client config. Claude Code:

claude mcp add myotp -e MYOTP_API_KEY=your-key -- npx -y @myotp/mcp

Claude Desktop, in claude_desktop_config.json:

{
  "mcpServers": {
    "myotp": {
      "command": "npx",
      "args": ["-y", "@myotp/mcp"],
      "env": { "MYOTP_API_KEY": "your-key" }
    }
  }
}

Restart the client. Ask it: "Send an OTP to +44 7700 900123 over SMS." Then: "Verify code 482917 for that number."

If your client can't launch local processes, point it at the hosted server instead: https://mcp.myotp.app/mcp, key in the X-API-Key header or as Authorization: Bearer. Add 108.61.176.199 to your key's IP allowlist for that, since hosted calls reach our API from that address and not from your machine.

What's in it

Ten tools. The four you'll use most:

generate_otp sends a code over SMS, WhatsApp or Telegram and returns a transaction id.
verify_otp checks what the user typed.
check_otp_status tells you whether the message was queued, sent, delivered or failed, which is where you look first when "the code never arrived".
extend_otp gives a slow user more time without sending a new code.

The rest cover the account: get_account_info, get_account_status, get_usage_report, and three that exist so an agent can run without a human in the loop. create_account registers a new account and returns a key, get_topup_quote and top_up_credits buy credits over HTTP 402 through Stripe, by card or USDC. An agent that runs out of credits can refill and carry on.

What it doesn't replace

The MCP server is a tool for the agent, not a dependency for your app. Your application still calls the REST API from the server side with the key in the X-API-Key header. The published examples for Next.js, Express, Flask, Django, Rails and Laravel are in the brntech/myotp-agentkit repo and are the copy-paste starting points.

The one thing that goes wrong

IP allowlisting. A key created from your laptop is allowlisted to your laptop's public IP. When the first call from a server or from the hosted MCP endpoint comes back with a 403 that says the IP isn't allowed, that's the cause, not the key.

Disclosure again: I work at MyOTP.App. If something here is wrong, say so in the comments and I'll fix the post.

Supabase phone auth without a built-in provider: the Send SMS Hook, step by step

Raya — Thu, 03 Sep 2026 22:14:44 +0000

Supabase ships phone auth with a short list of built-in SMS providers. If the one you want isn't on it, you're not stuck. There's a documented escape hatch called the Send SMS Hook, and it takes about three minutes to wire up. I work at MyOTP.App, so the walkthrough uses us, but the mechanism is the same for anyone who hosts a compatible endpoint.

What the hook is

Supabase doesn't send SMS. Phone login is auth logic, and the message has to leave through somebody's gateway. The provider dropdown is the built-in list. The Send SMS Hook replaces it: when a user requests a phone OTP, Supabase POSTs the code and the phone number to a URL you configure, and your endpoint delivers it however it likes.

Supabase keeps the code and does the verification. The hook is delivery only. Nothing changes in your client code.

Setup, in this order

The order matters. The endpoint URL is created from the secret, so the secret has to exist first.

In Supabase, open Authentication, then Hooks, then Send SMS Hook. Choose the HTTPS type and click Generate secret. Copy the value. It starts with v1,whsec_. Don't save the hook yet.
In your MyOTP dashboard, open Integrations, pick which application should pay for the messages, paste the secret, and create the integration. You get back a URL of the form https://api.myotp.app/v1/supabase/send-sms/<id>.
Back in Supabase, paste that URL into the hook, enable it, and save.

That's it. No SDK, no server code, nothing to deploy.

What Supabase sends

{
  "user": { "id": "8484b834-...", "phone": "919000000001" },
  "sms": { "otp": "123456" }
}

Requests are signed with the Standard Webhooks scheme: webhook-id, webhook-timestamp and webhook-signature headers, verified against the secret with the v1,whsec_ prefix stripped and the rest base64-decoded. If you write your own endpoint, don't skip this. An unauthenticated send-me-an-SMS URL on the public internet has a short and expensive life.

Two things that trip people up

Supabase wants an empty body with a 200. Return a friendly JSON receipt and Supabase may treat the call as failed, so the user sees an error while the SMS is already on its way.

Test with a phone in your hand. Hook failures, provider failures and route failures all look identical from the Supabase side.

Channels

Supabase hands over a code and a phone number and has no opinion about how the code reaches the person. The same hook can deliver over WhatsApp or Telegram instead of SMS. On our side that's a per-application setting. The Supabase side doesn't change.

When not to bother

If your current provider works and your users are all in one country where it delivers well, leave it alone. The hook earns its keep when delivery is patchy in the countries you care about, when per-verification fees stack on top of message cost, or when you want WhatsApp and Telegram without rebuilding auth.

Disclosure again: I work at MyOTP.App. The docs page for this integration is myotp.app/integrations/supabase and it links to Supabase's own hook documentation.