How to Validate Phone Numbers with an API (Without SMS Alone)

Introduction

A phone number field looks like the easiest part of a signup form. Someone types ten or so digits, you send a code, they type it back, and you move on. That flow feels safe, but it only proves one thing: the person had access to that number for a few minutes. It says nothing about whether the number is a throwaway, whether it is already on your blocklist, or whether it belongs to someone running hundreds of fake accounts.

That gap is the difference between phone verification and phone validation. Verification sends an SMS one-time password (OTP) and checks that the code comes back. Validation, done properly, is risk scoring: it looks at the number itself before you send anything and tells you how much you should trust it. This guide explains how a phone number validation API works, why disposable number detection matters so much, and how to combine scoring with SMS so you stop fake signups without punishing real users.

The timing matters, because signup is now the riskiest moment in the customer journey.

According to TransUnion's H2 2025 Update: Top Fraud Trends, 8.3% (or 1 in 12) of all new accounts created in H1 2025 were suspected to be fraudulent, a 28% increase over H1 2024.

Why Phone Numbers Became the Front Door for Fraud

Email addresses are free and unlimited, so many products moved to phone numbers as a stronger identity signal. The idea was simple. A phone number costs money, it is tied to a carrier, and most people only have one or two.

Fraudsters adapted quickly. Today they can rent disposable numbers from online services for a few cents, receive a single SMS, and drop the number. Some of these services publish their numbers openly on websites, so the same number may be used by many people. The result is that a phone number alone no longer proves a real, unique person is behind an account.

That does not make phone numbers useless. It means you need to judge the quality of the number, not just whether it can receive a text.

Know the Difference Between Phone Validation and Phone Verification

These two terms get mixed up all the time, and the confusion leads to weak signup flows.

Phone Verification (SMS OTP)

A phone verification API sends a one-time code by SMS or voice. The user enters the code, and you confirm they can receive messages on that number right now. It answers one question: "Does this person control this number at this moment?"

Phone Validation and Scoring

A phone validation API checks the number itself, usually in milliseconds and without sending anything. A basic validator only checks format. A scoring API goes further and answers a bigger question: "Should I trust this number at all?"

What a Scoring API Looks At

• Structure. Is the number valid for the country you expect?
• Disposable or spam status. Is this a throwaway or known spam number?
• Blocklist status. Has your team or your own rules already blocked it?
• Carrier. Which carrier the number belongs to, when available.
• An overall verdict. A risk level and a clear recommendation to accept, review, or reject.

Verification proves control. Scoring judges risk. You usually want both, in that order: score first, then decide whether an SMS is worth sending.

Stop Relying on SMS Codes Alone

SMS OTP is useful, but on its own it has three big weaknesses.

First, disposable numbers pass it easily. A rented number receives codes just fine, so the OTP succeeds and the fake account gets through.

Second, every SMS costs money. If bots submit thousands of numbers, you pay for thousands of messages. Some attackers do this on purpose to inflate SMS traffic and profit from it, a scheme often called SMS pumping or toll fraud.

Third, sending a code to a number that is not even valid wastes time and money and adds friction for a user who simply made a typo.

Scoring the number before you send the code fixes all three problems. Invalid numbers get caught as typos, risky numbers get blocked or reviewed, and you only spend SMS budget on numbers that look real.

Catch Disposable Numbers Before They Become Fake Accounts

Disposable phone number detection is where a scoring API pays for itself. A disposable number is the phone version of a temporary email inbox. It exists so someone can pass a check without tying the account to a real identity.

People use disposable numbers to:

1. Create many accounts to abuse free trials, sign-up bonuses, or referral rewards.
2. Get around bans after an account was closed for abuse.
3. Run spam, scam, or fake review operations at scale.
4. Hide their identity during payment or payout fraud.

Greip's Phone Scoring endpoint returns a flag that tells you whether the number is considered disposable or spam. When it is set, the response usually also carries a high risk level and a reject recommendation, along with readable reasons. You can block the signup, ask for another number, or send the account to manual review, depending on your product.

See How Greip Scores a Phone Number

Greip's Phone Scoring API is designed as an extra layer of protection for phone numbers. According to the docs, it not only checks the syntax but also assesses the likelihood of the number being valid and operational. It is part of Greip's broader data scoring and validation service, which covers both emails and phone numbers.

The request is a simple GET call:

• Endpoint: https://v2.greipapi.com/score/phone/{phone}
• Path parameter: the phone number you want to check.
• Required query parameter: the two-letter ISO 3166-1 alpha-2 country code, such as US.
• Authentication: your Greip API key, sent as a Bearer token in the Authorization header.

API v2 only accepts the key in the header, not in the query string or body. You can also pass an optional source label and a user identifier, which helps you trace requests from specific users on the Events page.

Reading the Response

Here is the sample response from the Greip docs for a number that fails the structure check:

{
  "success": true,
  "data": {
    "carrier": null,
    "is_valid": false,
    "is_blacklisted": false,
    "is_disposable": false,
    "phone": "+12121234567",
    "country_code": "US",
    "risk_level": "high",
    "recommendation": "reject",
    "reasons": ["Invalid phone number structure."],
    "custom_rules_applied": {
      "total": 0,
      "rules": []
    }
  },
  "execution_ms": 1
}

And here is what each field means, according to the docs:

carrier               Carrier name of the phone number (can be null)
is_valid              Passes structure and validation checks for the given country code
is_blacklisted        Blocked by your custom rules or found in one of your blacklists
is_disposable         Flagged as disposable or spam
risk_level            Overall risk band: low, medium, or high
recommendation        Suggested action: accept, review, or reject
reasons               Human-readable reasons for elevated risk (empty when risk is low)
custom_rules_applied  Total count and list of your custom rules that matched
execution_ms          Processing time in milliseconds

Notice that the structure check is only one input. The risk level and recommendation combine validity, disposable status, and your own blocklists into one decision you can act on.

Implement Phone Scoring in Your Signup Flow

You can call the endpoint from your backend in a few lines. Keep the API key on the server, never in browser or mobile app code.

Quick Test With cURL

curl --request GET \
  --url "https://v2.greipapi.com/score/phone/12121234567?country_code=US" \
  --header "Authorization: Bearer $GREIP_API_KEY"

While you build, you can add mode=test to the query string to use the development environment, as described in the Greip docs.

Node.js Example

// Node.js 18+ (built-in fetch)
const GREIP_API_KEY = process.env.GREIP_API_KEY;
async function scorePhone(phone, countryCode, userId) {
  const url = new URL(
    `https://v2.greipapi.com/score/phone/${encodeURIComponent(phone)}`
  );
  url.searchParams.set("country_code", countryCode);
  if (userId) url.searchParams.set("user_id", userId);
  const res = await fetch(url, {
    headers: { Authorization: `Bearer ${GREIP_API_KEY}` },
  });
  const body = await res.json();
  if (!body.success) {
    throw new Error(`Greip error ${body.code}: ${body.description}`);
  }
  return body.data;
}
async function handleSignupPhone(phone, countryCode, userId) {
  const result = await scorePhone(phone, countryCode, userId);
  if (!result.is_valid) {
    return { action: "ask_again", message: "Please check your phone number." };
  }
  if (result.is_disposable || result.is_blacklisted) {
    return { action: "block", reasons: result.reasons };
  }
  if (result.recommendation === "reject") {
    return { action: "block", reasons: result.reasons };
  }
  if (result.recommendation === "review") {
    return { action: "send_otp_and_review", reasons: result.reasons };
  }
  return { action: "send_otp" };
}

This flow treats an invalid number as a likely typo, so the user gets a friendly retry. Disposable or blocked numbers never receive an SMS. Everything else moves on to normal OTP verification.

Turn Scores Into Clear Decisions

The recommendation field gives you a sensible default, but your product decides what each outcome means. A simple starting policy looks like this:

• Accept. Send the OTP and continue normally.
• Review. Send the OTP, but limit sensitive actions such as payouts, bonus claims, or bulk messaging until the account builds some history.
• Reject. Do not send an SMS. Ask for a different number or show a neutral error.

If the default bands do not fit your business, Greip lets you add custom rules and blocklists in the dashboard. Matched rules show up in the response, so your team always knows why a number was flagged.

Real Scenarios Where Phone Scoring Stops Fake Signups

Free Trial and Promo Abuse

A SaaS company offers a 14 day trial. One user keeps coming back with new emails and new disposable numbers. Scoring the number at signup flags the disposable numbers and closes the loop that email checks alone leave open.

Marketplace Sock Puppet Accounts

A marketplace sees fake buyer accounts leaving reviews for one seller. Phone scoring blocks disposable and spam numbers, and the user identifier helps the team trace related requests on the Events page.

SMS Budget Protection

A fintech app notices SMS costs jumping overnight with no rise in real signups. Scoring numbers before sending codes filters out invalid and risky numbers, so the OTP provider is only used for numbers that look real. Greip has a page on this exact SMS fraud use case.

Gaming Bonus Hunters

A gaming platform gives a welcome bonus per phone number. Multi-accounters rotate through rented numbers. A disposable flag at signup removes most of the incentive before the bonus is ever paid.

Handle the Tricky Edge Cases

No single signal is perfect, so build with a few edge cases in mind.

Wrong country codes. The country code is required, and the same digits can be valid in one country and invalid in another. Use the country the user selects in your form, or a sensible default from their location, and let them change it.

Legitimate privacy users. Some real people use secondary numbers for privacy. A review path, rather than a hard block, keeps you from losing them when the risk is only medium.

Missing carrier data. The carrier field can be empty. Treat it as extra context, not as a reason to block on its own.

Errors and timeouts. If the API returns an error, such as an invalid key, decide on a safe fallback. Many teams fall back to OTP plus extra review rather than blocking everyone.

Best Practices for Phone Number Validation

1. Score before you send. Always run phone scoring before the OTP, never after.
2. Combine signals. Pair phone scoring with email scoring and IP checks such as VPN and proxy detection. A disposable number on a VPN connection is a much stronger signal than either alone.
3. Fix typos kindly. Invalid numbers are often honest mistakes. Show a clear message and let the user retry.
4. Log the reasons. Store the risk level and reasons with the account so support and fraud teams can see why a decision was made.
5. Respect privacy laws. Phone numbers are personal data. Only collect what you need, explain why in your privacy notice, and follow the rules that apply to you, such as GDPR. Talk to your legal team about your specific obligations.
6. Test before launch. Use test mode while you integrate so you do not affect live data.

If you want to try the checks manually first, Greip also offers a free phone number validator tool.

Where Phone Risk Scoring Is Heading

Fraud teams are moving away from single yes or no checks and toward layered risk scores. A phone number is now one signal among many, scored together with email, IP, device, and behavior data.

Expect three trends to keep growing. More products will score numbers silently before any SMS is sent, so real users see less friction. Disposable number detection will matter more as rental services grow. And teams will rely more on their own custom rules and blocklists, tuned to the abuse patterns they actually see.

Frequently Asked Questions

What is the difference between a phone validation API and a phone verification API?

A phone verification API sends an SMS or voice code to confirm the user controls the number. A phone validation or scoring API checks the number itself, including structure, disposable or spam status, and blocklists, and returns a risk level without sending a message.

Can a phone validation API detect disposable phone numbers?

Yes, if it includes risk scoring. Greip's Phone Scoring endpoint returns a flag showing whether the number is considered disposable or spam, along with a risk level, a recommendation, and readable reasons.

Do I still need SMS OTP if I use phone scoring?

In most cases, yes. Scoring tells you whether a number is worth trusting, and OTP proves the user controls it. Use scoring first to filter risky numbers, then send OTP only to numbers that pass.

Which parameters does the Greip phone scoring endpoint need?

You send the phone number in the path and a two-letter country code in the query string. You authenticate with your Greip API key as a Bearer token in the Authorization header.

Is phone scoring fast enough for signup forms?

The endpoint returns a processing time in milliseconds with each response, and the sample in the docs shows 1 ms of processing. Network time adds a little on top, but it is generally quick enough to run inline at signup.

Does phone validation help reduce SMS costs?

It can. By filtering out invalid, disposable, and blocked numbers before sending a code, you avoid paying for messages that would only serve fake or mistyped signups.

Conclusion

Sending an SMS code is not the same as trusting a phone number. Verification proves someone can receive a message. Validation with risk scoring tells you whether you should care about that number in the first place.

The strongest signup flows do both. Score the number first with a phone validation API, catch invalid entries as typos, block disposable and blocklisted numbers, and send OTP only to numbers that look real. That approach cuts fake accounts, protects your SMS budget, and keeps the experience smooth for genuine users.

If you are ready to add this layer, start with the Greip Phone Scoring docs, run a few numbers in test mode, and build a simple accept, review, and reject policy around the results.