Monitor OTP/SMS
Check that your OTP/SMS reaches a real phone on an international number, and how long it took.
- 1 corridor, 1 number, 3 authorized senders
- 3,000 checks / month
- 1 GB evidence storage
- 50,000 API requests / month
- 90-day retention
The problem
You don't have end-to-end visibility of your own OTP/SMS flow (provider to carrier to phone). You don't know if a code was lost, delayed, or if the sender/content arrived intact.
Who it is for
Any company that sends OTP/SMS to end users and needs independent visibility into whether the code really arrives on a real phone.
What you send us
| Field | Format | Validation |
|---|---|---|
| authorized_senders | One or more: E.164 number, or 3-11 char alphanumeric sender ID | Never a wildcard ("*"); matched exactly, case-insensitively, never as a substring |
| correlation_token | 6-32 chars, letters/digits/hyphen | Required: your OTP SMS must include a correlation token of 6-32 characters that you choose (e.g. WT-ACME); it lets us match your message to your check |
| expected_window_seconds | Integer, 60-3600 | Defaults to 900; the run must land inside this window to count as received |
| max_latency_seconds | Integer | Optional ceiling on top of expected_window_seconds |
| forward_webhook_url | https:// URL | Optional; must be https://, same SSRF-safe URL check as every other webhook field |
| country_code | 2-letter code | Must be one of your plan’s included corridors |
You send the OTP from your own provider to a number you authorize; Witnio never sends the OTP itself, it only receives and measures it.
What runs
- An arriving SMS is detected on the worker’s next read of the receiving phone’s inbox — every worker cycle, about 80 seconds measured across the fleet — so typically within 2 minutes.
- The sender is matched against authorized_senders_json exactly; a non-matching sender is not attributed to your check.
- Content integrity is checked but the OTP itself is masked before it is ever persisted or sent to AI.
- An incident opens once failure_threshold is exceeded within expected_window_seconds.
What you get
- One MonitorRun per event (status, latency_ms, evidence_json)
- Alerts (Telegram/email)
- Dashboard
- API/webhook per plan
Limits & quotas
Loading...
Autonomy
Every OTP event is observed and evidenced unattended. Human escalation triggers only when failure_threshold is exceeded inside the expected window, or when a sender fails to match any authorized_senders entry repeatedly.
Compliance
Each plan declares its corridor (number country, hosting country, access method). Delivery is observed on a real handset reached through an international number; it is not a measurement of in-country network performance, delivery or mobile latency. The corridor context is recorded inside every signed evidence record and shared on request.
Evidence
Known limitations
- Delivery is observed on a real handset reached through an international number. It does not show how the same message is delivered on US or other in-country networks.
- A number reached via roaming or Wi-Fi calling is never sold as that country's "network" or "mobile latency".
- Doesn't replace your SMS provider — it only audits it.
- Activation requires proof that you control your company domain (a DNS TXT record shown at checkout, before payment). If your account e-mail is on a free provider (Gmail, Outlook...), we verify your company manually, usually within 1 business day.
Questions about this service
Related guides
- How do you verify that OTP codes are actually delivered to real phones?
- How do you verify that outbound calls actually ring, and what caller ID the recipient sees?
- What is the difference between compliance evidence and a compliance certification?
- What should an A2P 10DLC delivery verification checklist include?