# SaaS free-trial and sign-up abuse

> Score SaaS and AI-product sign-ups by line type, reachability, mailbox existence and spam reputation, spot repeated test patterns, and add friction only where the signals call for it.

Canonical: https://mobilevalidate.com/use-cases/saas-free-trial-abuse · Last updated: 2026-09-29

![A laptop shows a cURL request and a JSON response next to tiles for REST API, SDKs, webhooks and test mode, under the headline One API, 42 checks, 5 families.](https://mobilevalidate.com/media/library/developer-one-api-42-checks-1600.webp)

*One API, 42 checks, 5 families; pay only for conclusive answers.*


SaaS free-trial abuse is repeated sign-ups by the same people to reuse free trials, credits or free tiers. Checking the phone number and e-mail at sign-up gives you quality signals: line type, whether the mobile line is live, whether the mailbox exists and, where enabled, spam reputation. Use them to add friction selectively, never as identity claims.

## Why is free-trial abuse hard to stop?

Free trials and free credits exist to let real prospects try the product. AI products have raised the stakes: a free tier that includes model usage has a direct compute cost per account, so each abusive sign-up costs real money, not just a seat in a database. The people farming trials know the usual defences:

- **Throwaway e-mail addresses.** Invented or short-lived addresses at big webmail providers, or variations such as `name1@`, `name2@`, `name3@`.
- **Cheap phone numbers.** Numbers from VoIP apps and online number services pass a format check and can often receive a code.
- **Automation.** Scripts create accounts in bursts, often following a visible pattern in the addresses or numbers they use.
- **Real people, repeatedly.** Some abuse is simply one person who never wants to pay, using a new address each month.

No single signal separates abusers from new users. What helps is a handful of cheap, explainable signals, combined with your own data, feeding a decision that adds friction only where it's needed. The [OWASP Automated Threats project](https://owasp.org/www-project-automated-threats-to-web-applications/) lists account creation (OAT-019) as a distinct automated threat worth designing for.

## Which sign-up signals help?

- **Line type.** The [carrier lookup](/services/carrier-lookup) reports `mobile`, `fixed_line`, `voip` and other types. A VoIP number isn't bad on its own, but it changes how much trust a phone number adds. See [VoIP number](/glossary/voip-number).
- **Reachability.** The [HLR lookup](/services/hlr-lookup) says whether a mobile number is assigned and reachable now. An unassigned number (`status: invalid`) can't be a real user's phone.
- **Mailbox existence.** The [e-mail mailbox check](/services/email-verification) answers whether the mailbox exists at major webmail providers. A made-up address fails here before you spend a verification e-mail on it.
- **Spam reputation** (limited access). [Spam reputation](/services/spam-reputation) reports regulator actions, complaint data, community reports and recently unassigned numbers, with the reasons.
- **Repeated test patterns.** Look in your own sign-up data for addresses that differ only by digits, sequential phone numbers, or many sign-ups from one device or network. The API applies its own anti-enumeration rules: a request with 20 or more consecutive numbers, or 20 or more addresses on one domain that differ only by digits, is refused with `suspected_enumeration`.

None of these signals says who someone is. They say how much a given number or address is worth as evidence of a real, reachable user.

## How does the workflow look?

1. **Normalize.** Pass the number as entered with `default_country` if needed; the API converts it to [E.164](/glossary/e164).
2. **Check.** Call `POST /v1/lookup` with the number and address and `checks: ["carrier", "email"]`, plus `hlr` or `spam` if you use them. Use `wait: 5`.
3. **Score.** Combine the results with your own signals (device, IP reputation, payment method, prior accounts) into a tier: full trial, reduced trial, or verify first.
4. **Apply friction by tier.** Full trial for strong signals; a smaller credit allowance or a second factor for mixed signals; card or manual review for weak ones.
5. **Don't block on missing data.** `unknown` and `pending` count as neutral.
6. **Log the decision** with `checked_at`, not the raw response, and review your thresholds regularly against real conversion and abuse data.

## Which checks answer which question?

| Check | What it answers | When to run it | Link |
|---|---|---|---|
| `carrier` | Mobile, VoIP, fixed line or another type? | Every sign-up with a phone number | [Carrier lookup](/services/carrier-lookup) |
| `email` | Does the mailbox exist at a major webmail provider? | Every sign-up | [E-mail mailbox check](/services/email-verification) |
| `hlr` | Is the mobile number assigned and reachable now? | Sign-ups that unlock paid resources | [HLR lookup](/services/hlr-lookup) |
| `spam` (limited access) | Is the number in spam or fraud reports? | Where enabled for your account | [Spam reputation](/services/spam-reputation) |
| `whatsapp` | Is the number registered on WhatsApp? | Optional extra weight for a real, in-use number | [WhatsApp number check](/services/whatsapp-number-check) |

## What should you do with each result?

| Signals | Suggested tier |
|---|---|
| Mobile line, reachable, mailbox exists | Full trial |
| Mobile line, mailbox `unknown` (company domain) | Full trial; company domains are often outside mailbox coverage |
| `line_type: voip` and an otherwise clean session | Reduced credits, or a second factor before the full allowance |
| Mailbox `registered: false` | Ask the user to fix the address before the trial starts |
| HLR `status: invalid` | Ask for another number; this one isn't assigned |
| Spam `risk_level: high` (if enabled) | Verify first: card check or manual review |
| Pattern match in your own data (e.g. `name7@`, `name8@` minutes apart) | Verify first, and review the burst |
| Checks `unknown` or `pending` | Neutral; decide on your other signals |

## What does a request look like?

This test-mode request checks one number and one address. `+447700900002` has no carrier data (`unknown`, free) and `not-registered@test.mobilevalidate.com` has no mailbox.

```bash
curl https://api.mobilevalidate.com/v1/lookup \
  -H "Authorization: Bearer $MOBILEVALIDATE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"numbers": ["+447700900002"], "emails": ["not-registered@test.mobilevalidate.com"], "checks": ["carrier", "email"], "wait": 5}'
```

Response (excerpt, test mode: the `checks` of the phone row, then of the e-mail row):

```json
[
  {
    "network.carrier": {
      "service": "network.carrier", "status": "unknown", "registered": null, "attributes": null,
      "confidence": null, "confidence_score": null, "checked_at": null,
      "cached": false, "age_seconds": null, "billed": false, "reason": "NO_DATA", "poll_after_ms": null
    }
  },
  {
    "email.valid": {
      "service": "email.valid", "status": "completed", "registered": false, "attributes": null,
      "confidence": "high", "confidence_score": 0.99, "checked_at": "2026-09-29T11:20:05.733Z",
      "cached": false, "age_seconds": 0, "billed": false, "reason": null, "poll_after_ms": null
    }
  }
]
```

The carrier answer is neutral and free. The mailbox doesn't exist, so the sign-up form asks for a working address before the trial starts.

## How much does it cost?

You pay per check, and only for conclusive answers. Unknown answers are free, as are invalid input, duplicates and unsupported countries. A two-check sign-up bills at most two checks. The HLR lookup is $0.005 per number; see [pricing](/pricing) for the carrier, e-mail and other rates.

Compare that with what an abusive account costs you: free credits consumed, compute, support tickets and skewed funnel data. Most teams run the cheap checks on every sign-up and the HLR or spam check only on sign-ups that unlock expensive resources. Repeat checks of the same number inside the freshness window come from your cache for free, and `max_cost` caps any single request.

## What about consent and compliance?

- **Tell users.** Say in your privacy notice that you check phone numbers and e-mail addresses at sign-up to prevent fraud and abuse.
- **No identity claims.** The results are risk signals about a number or an address. Don't present them to users or staff as identity verification, and don't use them for credit, employment, housing or insurance decisions.
- **Proportionate friction.** Give flagged users a way through: a second factor, a card check or a support contact. Genuine users with VoIP numbers or new addresses exist.
- **Data minimization.** Store the tier and `checked_at`, not full responses. Our [privacy checklist](/blog/privacy-checklist-for-phone-and-email-checks) lists the questions to settle before launch.
- **Only your own sign-ups.** Check the details people give you. Our [acceptable use policy](/legal/acceptable-use) forbids enumerating numbers or addresses.

## What are the common mistakes?

- **One hard rule.** "Block all VoIP" loses real customers and teaches abusers to buy a different number type. Use tiers.
- **Treating unknown as fraud.** Company domains and slow networks return unknown. It's neutral.
- **Checking after the credits are granted.** Run the check before the trial allowance is unlocked.
- **Retrying around `suspected_enumeration`.** If the API refuses a request as a pattern, review the burst of sign-ups instead of splitting the request.
- **Never re-tuning.** Abuse patterns change. Compare your tiers with actual conversions and abuse every month.

For the OTP side of the same problem, see [OTP and sign-up fraud](/use-cases/otp-and-signup-fraud).

## Frequently asked questions

### What is free-trial abuse?

It is when one person or group signs up again and again to keep using a free trial, free credits or a free tier, usually with throwaway phone numbers and e-mail addresses. It costs compute, support time and distorted conversion data.

### Which signals help at sign-up?

Line type (mobile, VoIP, fixed line), whether the mobile line is reachable, whether the e-mail mailbox exists, spam reputation where enabled, and patterns in your own sign-up data such as many addresses that differ only by a number.

### Should I block VoIP numbers?

Usually not. Many real users have VoIP numbers, especially in business settings. Treat VoIP as a reason for a smaller trial, a second factor or a card check, not as an automatic block.

### Does this identify the person behind a sign-up?

No. The checks describe the number or the address, never the person. We don't return names, profiles or linked accounts, and the results must not be used as identity verification.

### Do you detect disposable phone numbers or disposable e-mail domains?

We don't sell a disposable-number or disposable-domain list. The carrier lookup reports VoIP line types and the mailbox check reports whether an address exists at major webmail providers; combine those with your own rules.

### How fast is the check in a sign-up flow?

POST /v1/lookup waits up to 30 seconds (default 10). For sign-up, pass a short wait such as 5 seconds; anything still pending can finish in the background while the user continues.

### What does an unknown answer mean?

No conclusive answer, for example after a timeout or for an e-mail provider we don't cover. It is not charged, and it should not count against the user.

### Is spam reputation available to every customer?

Not yet. Spam reputation is in limited access (internal customers only). The carrier, HLR and e-mail checks are available to all customers.