otp-watch is synthetic monitoring for the one thing your status page can't see: whether the verification SMS or email your users need to log in is actually being delivered, and how fast. Rent a real target, send your own code to it, get told when it breaks.
Email checks free · 3 free SMS checks · SMS monitors €29/moEnter any email to get a free API key instantly:
Your API key (save it — it won't be shown again):
The SMS monitor gives you a real UK number for unlimited SMS checks — the same number all month. Card payment via Stripe, cancel anytime.
otp-watch rented you a real inbox. Send your app's verification email to:
Prefer the API directly? See the curl version just below.
Your auth provider returns 200 OK. Your uptime check is green. And yet a carrier filter, a spam-folder change, a suspended sender domain, or a broken SMS route means a chunk of your users never receive their code and simply can't sign in. You find out from a support ticket, days later. otp-watch closes the loop by actually receiving the message end to end, the same way a user would.
# get an API key
curl -X POST https://otpwatch.flo-voice1.com/keys \
-H 'content-type: application/json' -d '{"email":"you@example.com"}'
# => {"key":"ow_..."}
# start a check — you get back a real disposable address
curl -X POST https://otpwatch.flo-voice1.com/checks \
-H 'authorization: Bearer ow_...' \
-H 'content-type: application/json' -d '{"channel":"email"}'
# => {"id":"chk_...","target":"a1b2c3@receivemail.dev","status":"pending"}
# trigger your app's verification email to that address, then poll:
curl https://otpwatch.flo-voice1.com/checks/chk_... \
-H 'authorization: Bearer ow_...'
# => {"status":"received","latencyMs":4200} (or "timed_out")
received with a latency figure, or timed_out. Your own cron or CI job turns that into an alert — a red build is the alert.A one-off SMS check rents a fresh number each time — fine for a manual test, too expensive to run every 15 minutes. A monitor rents one real number for the month and reuses it for unlimited checks against that same number. The number can change when the month renews — always read it from GET /monitors.
# create a Stripe Checkout session for a monitor
curl -X POST https://otpwatch.flo-voice1.com/monitors/checkout \
-H 'authorization: Bearer ow_...'
# => {"checkoutUrl":"https://checkout.stripe.com/..."}
# after payment, the monitor exists:
curl https://otpwatch.flo-voice1.com/monitors -H 'authorization: Bearer ow_...'
# run a check against it — no new rental:
curl -X POST https://otpwatch.flo-voice1.com/monitors/MON_ID/checks \
-H 'authorization: Bearer ow_...'
| Endpoint | Description |
|---|---|
POST /keys | Issue an API key. Body {"email":"..."}. |
POST /checks | Start a one-off check. Body {"channel":"sms"|"email","timeoutSeconds"?:number}. Returns a real target and a check id. Email is unlimited; SMS uses your free trial allowance (402 once it's spent). |
GET /checks/:id | Poll a check: pending → received (with latencyMs) or timed_out. |
GET /usage | How many free SMS checks your key has left. |
POST /monitors/checkout | Get a Stripe Checkout URL for a €29/mo SMS monitor. |
GET /monitors | List your active monitors. |
POST /monitors/:id/checks | Run a check against an existing monitor's number — no new rental. |
POST /monitors/portal | Stripe billing-portal link to cancel or manage a monitor. |
Email delivery checks, unlimited — one-off or on your own schedule. Powered by receivemail.dev. Includes 3 free one-off SMS checks per key to try the SMS side, since each of those rents a real number.
Per SMS monitor. A real UK number kept for the whole month (it can change at renewal), unlimited checks, cancel anytime from the billing portal. Billed through Stripe.
No. It only provides the target and receives what lands there. You trigger the send from your own system, so the whole path — your provider, the carrier, the inbox — is exercised exactly as it is for a real user.
For continuous monitoring, yes — by design. otp-watch deliberately has no scheduler or alerting in v1. Your CI or cron calls it on whatever interval you want and fails loudly on timed_out. That keeps the service small and lets your existing alerting stack own the paging.
UK numbers today (same real-SIM hardware pool as sms-florin). If you need other countries for delivery monitoring, get in touch.
An uptime monitor confirms your API answered. otp-watch confirms a human on the other end would have received the code. Those are not the same check, and only the second one tells you your login flow still works.
FAQ: pricing, timeouts, CI usage and limits
How to monitor whether your OTP codes actually get delivered
How to test your Twilio Verify / OTP integration without burning SMS credits