Choose a Verify API by testing it on your own flows: code delivery speed and completion in your top countries, automatic fallback across channels, billing rules your finance team can forecast, abuse controls and logs your support team can actually use. Feature lists look alike; the differences show up only in production traffic.
This checklist covers what a phone verification API should do, what to measure, which tests to run in a week, and which questions to put to every vendor.
What does a Verify API do that an SMS API does not?
You can send a code with a plain SMS API. But then your team builds and maintains everything around it. A Verify API takes that workload off you.
| Task | With a plain SMS API | With a Verify API |
|---|---|---|
| Generate and store the code securely | You build it | Handled, or you pass your own code |
| Expiry and attempt limits | You build it | Configured per app or per request |
| Delivery on several channels | Separate integrations | One call with a channel order |
| Fallback when a channel fails | Your own timers and retry logic | Automatic |
| Confirming the code | Your own comparison logic | One confirm call |
| Audit trail per verification | Stitched together from logs | One record with every attempt |
Once verification volume is meaningful, that orchestration is the product. The channel is just transport.
What should you define before talking to vendors?
The events you will protect. List them and give each a risk tier: new account signup, login from a new device, password reset, adding a payout method, approving a high-value transaction, changing the phone number on file. High tiers get shorter expiry, tighter limits and possibly a stronger factor.
What success means. Choose metrics you will compare providers on, even if you do not know the targets yet:
- Verification completion rate by country
- Median and 90th percentile time from request to delivery
- Share of verifications that needed fallback
- Resend rate and drop-off during verification
- Cost per successful verification, by country
- Support tickets per 10,000 verification attempts
Your channel policy. NIST SP 800-63B-4 classes one-time codes sent over the phone network (SMS or voice) as a restricted authenticator. Services using them must offer at least one unrestricted alternative, explain the risk to users, and should consider signals such as device swap, SIM change and number porting before sending (NIST SP 800-63B-4, sections 3.1.3.3 and 3.2.9). That does not rule SMS out. It means your plan needs an alternative for high-risk users and a way to treat number changes as suspicious.
Which channels and fallback rules should it support?
A Verify API should deliver codes on the channels your users open, and switch between them without code on your side. Ask each provider to show:
- Channel availability by country, including any sender ID registration you need first
- Onboarding steps for OTT channels such as WhatsApp or Viber, including template approval
- Exactly what triggers fallback: a failed delivery report, a timer, or both
- How long each channel waits before the next one is tried, and whether you can set that per channel
- Whether delivery stops once one channel succeeds, so the user never holds two live codes
- Whether you can override the channel order, expiry and template on a single request
Test it rather than trusting the answer: set the first channel to an app that is not installed on a test phone and confirm that the fallback message arrives within your window, once. Our guide to multichannel OTP flows with smart fallback covers channel order and timing in detail.
How should Verify API pricing work?
Expect two layers of cost: the delivery fee for the channel and a verification fee for the service. What matters is how they behave when fallback happens. Ask every provider:
- Is the verification fee charged per attempt, per delivery or per successful verification?
- Are OTT channels charged if they do not deliver?
- Is SMS charged on send or only on delivery?
- Are skipped fallback channels ever charged?
Then model your own traffic. For example, take 100,000 verification attempts a month where 70% deliver on the first channel, 20% need fallback and 10% fail everywhere. Your finance team should be able to calculate channel fees, verification fees and the worst-case spend during an abuse spike from the provider’s published rules. If a vendor cannot walk you through that calculation, the invoices will be hard to explain later.
Also ask for cost controls: daily volume caps and alerts, per-country price visibility and the ability to block a destination instantly if SMS pumping starts. Our guide to SMS pricing and character limits explains the SMS side of the bill.
Which security and abuse controls matter?
Verification endpoints are cheap to attack. Expect OTP request floods to premium destinations, bots enumerating which numbers have accounts, brute-force guessing of codes and account takeovers via SIM swap. SIM swap is not theoretical: the FBI’s Internet Crime Complaint Center recorded 982 SIM swap complaints and $25,983,946 in reported losses in 2024 (IC3 2024 Internet Crime Report), and UK fraud prevention service Cifas reported nearly 3,000 unauthorised SIM swaps in 2024, up 1,055% on the year before (Cifas).
Controls to require:
- Rate limits per phone number, IP address and device, with resend cooldowns
- A cap on wrong-code attempts per verification (NIST sets an outer limit of 100 consecutive failures; most products use far fewer)
- Expiry you can shorten per request for high-risk actions
- A way to cancel an active verification when the user requests a new one
- Number checks before sending, such as HLR or MNP lookup, to catch invalid or recently ported numbers
- Signed or otherwise authenticated webhooks, so nobody can post fake “verified” events to your endpoint
What visibility do you need from webhooks and logs?
If support cannot see what happened to a code, they guess, and users pay for it. At minimum you want a verification ID you store with the user session, an event per delivery attempt and channel, a clear final status (such as verified, expired, failed or cancelled) and timestamps for each step.
With SMS.to, you can pull the full record of one verification, including each channel tried and its status:
curl https://verifyapi.sms.to/api/v1/verifications/3-1749636-f945-113c-a0499efc-4f9372d \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json"A list endpoint (GET /api/v1/verifications/list) filters by date range, status, application and recipient, which is what you need when one market suddenly underperforms. On your side, build the webhook handler to respond quickly, verify authenticity, process events idempotently so duplicates do not corrupt state, and keep a timeline for audits.
Do templates and localisation affect verification?
Yes, in two ways. Clarity: the message should say who it is from, the code, how long it is valid and what to do if the user did not ask for it. Cost: a single SMS holds 160 GSM-7 characters, but one non-GSM character, such as an emoji or a non-Latin letter, switches the whole message to UCS-2 with a 70-character limit. Look for per-language templates with variables, so each market gets a short, native message that fits in one segment.
How do you test a Verify API in a week?
- Real devices in five markets. Include one where you know delivery is slow. Record time to delivery, fallback behaviour and completion.
- Forced fallback. Use a test phone without the first channel’s app. Confirm one fallback message, on time.
- A high-risk flow. Run a payout change with shortened expiry and tighter limits, set per request rather than through a second integration.
- Simulated abuse. Fire repeated requests for one number and bursts from one IP range. Limits should trigger predictably, legitimate users should still get through and logs should show what was blocked.
- Invoice check. Ask for a charge breakdown of your test traffic (delivered first time, delivered after fallback, failed, expired) and compare it with the published rules.
What should your scorecard include?
Score each area from 1 to 5 and write down the evidence from your tests.
| Area | What to check |
|---|---|
| Delivery and UX | Time to code in key markets, resend share, fallback as configured, one clear message |
| Security | Rate limits, attempt caps, cancel support, webhook authenticity, number-change handling |
| Visibility | Searchable logs, per-attempt events, exports, completion and drop-off charts |
| Pricing | Clear rules for attempts, delivery and verification; fallback charges; caps and alerts |
| Team workload | What you configure yourself, SDKs for your stack, support response during incidents |
If you are shortlisting providers, our comparison of OTP API providers is a useful starting list.
How SMS.to handles phone verification and 2FA
The SMS.to Verify API is built around one Verify App per product: you set channel order, expiry, code length or format, templates and language once, then override any of them per request. Codes go out over SMS, WhatsApp, Viber and Telegram, with automatic fallback when a channel stalls. You can also bring your own code and let Verify handle delivery, limits and confirmation.
Billing follows published rules. For WhatsApp, Viber and Telegram you pay the channel fee only if it delivers. For SMS, the send fee applies when the message is sent, even if it is not delivered. The Verify fee applies only when the user verifies, and skipped channels are never charged. Webhooks, searchable logs and charts show completion, drop-off and fees, and the Verify page recommends pairing it with rate limits, CAPTCHA on repeat attempts and HLR or MNP lookups. SMS.to is run by Intergo Telecom, a licensed telecom and CPaaS operator.
FAQs
What is the difference between an OTP and a Verify API?
An OTP is the one-time code itself. A Verify API is the service that generates or accepts that code, delivers it on one or more channels, enforces expiry and attempt limits, and confirms whether the user entered it correctly.
Is SMS still acceptable for phone verification and 2FA?
Yes, for most consumer flows, but NIST SP 800-63B-4 classes SMS and voice codes as restricted. That means offering at least one alternative, telling users about the risk, and watching for SIM changes and porting before relying on it for high-risk actions.
How is a Verify API usually priced?
Most providers combine a channel delivery fee with a verification fee. Ask when each fee applies: on attempt, on delivery or on successful verification, and whether failed or skipped fallback channels are charged.
How long does it take to evaluate a Verify API?
About a week of focused testing is usually enough: real devices in your top markets, a forced fallback test, a simulated abuse spike and a check of the resulting charges against the provider’s published rules.
Evaluating providers for a high-volume or regulated flow? Talk to our sales team about a test plan for your markets and a pricing model you can forecast.
