How to check if a phone number has a Netflix, Amazon or Microsoft account (and what it tells a fraud team)

To check if a phone number has a Netflix, Amazon or Microsoft account, send it to an account-presence API with checks: ["netflix", "amazon", "microsoft"]. Each check runs in real time and in bulk, for numbers from any country, and returns registered, not registered or unknown with the time of the check. It never returns account details, subscription status or a name.

That is what a Netflix account number lookup can honestly do: answer one yes/no question about an identifier. For a fraud team, the value isn't the brand. It's what the answer suggests about the number. A number that signs in to a streaming subscription, a shopping account or a PC has usually been someone's everyday number for a while. A number bought an hour ago for a fake sign-up usually hasn't. This guide covers what each check means, how to run it, how to weigh the answers next to network data, and the uses we refuse.

#What does a Netflix, Amazon or Microsoft check tell you?

It tells you whether the service has an account that uses the number as a sign-in or contact identifier. All three services let people sign in with a phone number, which is why a number can be linked to an account at all:

Each check answers with the service's own registration signals. You get a boolean, a status and a timestamp, nothing about the person behind the account.

#Why does account presence matter to a fraud team?

Because established identifiers collect accounts and throwaway identifiers don't. Fake-account operations need many fresh numbers and addresses, quickly and cheaply. Nobody has used those identifiers to order deliveries, reset a laptop password or sign in to a TV. A real customer's number, by contrast, picks up accounts over years of ordinary life.

So a yes on a mainstream consumer service is evidence that the number belongs to a long-lived, real user. That makes it useful in four places:

• Sign-up risk scoring. One input to a score, next to line type and reachability. Our guide to building a phone number risk score shows the points-and-reason-codes method.
• Promotion and free-trial abuse. Repeat claimers rotate through fresh numbers. Presence lets established numbers through with no extra step, as described in promo abuse and multi-accounting and the free-trial abuse playbook.
• Marketplace trust. A new seller or buyer whose number has history on large consumer services is less likely to be a disposable identity. See marketplace trust and safety.
• Lead quality. An invented or mistyped number rarely has a shopping or streaming account. A real consumer's number often does.

The principle is asymmetric, and it's covered in depth in our guide to account-presence signals at sign-up: presence is informative, absence is ambiguous. This post focuses on these three services and how to read them.

#Which checks exist, and in which modes?

All three phone checks run in real time and in bulk, for numbers from any country except sanctioned ones. The e-mail side differs by service:

Two details trip people up. The alias netflix means the phone check; for addresses you must write netflix.email (the same goes for amazon.email). And there is no Microsoft e-mail account check: the Outlook e-mail check answers whether an Outlook address exists, in bulk jobs only. The Apple Account check is the natural fourth signal; our guide on checking a number for an Apple ID explains it. The services reference is the full list.

#How do I run the check in real time or in bulk?

Use POST /v1/lookup for decisions inside a user flow and POST /v1/jobs for lists. A real-time request mixing phone and e-mail checks, with test values:

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

With a test key, +447700900001 answers registered: true on every yes/no check, +447700900002 answers false, and +447700900003 answers unknown with reason: "UPSTREAM_TIMEOUT". The e-mail row gets only the e-mail check. Phone checks run on numbers and e-mail checks on emails. Each result sits under checks["netflix.registered"], checks["amazon.registered"] and so on, with registered, status, confidence, checked_at, cached, billed and reason. The lookups docs show the full shape.

A request holds up to 100 identifiers and 20 checks. If an answer isn't ready within wait, you get 202 with a poll URL. In a sign-up flow, don't make the user wait for it: treat pending as unknown and decide with what you have.

For a list, such as auditing accounts created during a promotion, use a bulk job of up to 50,000 identifiers. Run the free POST /v1/jobs/estimate first: it returns the valid, invalid, duplicate and cached counts and the maximum cost. Current per-check prices for real time and bulk are on the pricing page.

#How should I read yes, no and unknown?

Read every answer as a dated observation, not a fact about a person:

Three facts shape the weights:

• Netflix accounts are shared. One account usually covers a household, and only one account can hold a given verified number. Most household members will answer false on their own numbers.
• Amazon accounts can be e-mail only. A loyal customer who never added a number answers false.
• Numbers are recycled. Microsoft notes that "mobile carriers can reuse phone numbers after 30-days", so a previous owner may still have the number on an account (Microsoft). Keep checked_at, re-check when a user changes their number, and remember that a yes describes the number's history, not necessarily the person in front of you.

Never coerce unknown to false. An unknown means you learned nothing, and a score that treats it as absence will punish users for a timeout.

#How do I combine presence with HLR and line type?

Presence answers "has this number been used?" Network checks answer "is this a live mobile number right now?" Run them together. The HLR lookup reports whether a mobile number is reachable, and the carrier lookup returns line_type. A starting decision table:

If you use points, keep presence as a capped credit: for example, minus 1 per true up to minus 2, and zero for false. Absence should never be able to push a user past a light friction step by itself. Calibrate on your own outcomes; the SaaS free-trial abuse and OTP and sign-up fraud use cases show where these checks sit in each flow.

#What does the check never return?

It never returns anything about the account beyond its existence. Specifically, no check returns:

• A name, photo, username, gamertag or profile. We don't do reverse lookups from a number to a person.
• Subscription or plan status. A Netflix yes does not say whether the account is paid, paused or cancelled.
• Orders, addresses, payment data or viewing history.
• The e-mail address on the account, or any other identifier linked to it.
• Devices, locations or sign-in activity.
• Inferences about the person. We don't infer age, gender, income or any other trait, and you must not use presence as a proxy for them.

That narrow shape is deliberate. A dated boolean is enough to judge whether an identifier looks established, and it's too little to be useful to someone who wants to profile or attack a person.

#Which uses do we refuse?

We refuse any use that turns presence into reconnaissance against people. In particular:

• Account takeover reconnaissance. Checking whether a person's number or address has an account so you can try to break into it.
• Credential stuffing targeting. Filtering leaked credential lists down to identifiers that have accounts, so attacks waste fewer attempts.
• "Find accounts to attack" or "find all users". Scanning ranges of numbers or generated addresses to discover who uses a service.

Our acceptable use policy forbids breaking the law, enumerating identifiers, profiling individuals, and checking accounts without a lawful basis that covers that specific check. We enforce it technically too. A request with 20 or more consecutive numbers is refused with 403 suspected_enumeration. So are 20 or more addresses on one domain that differ only by digits or separators, or, with live keys, 50 or more of one such pattern per account per day. Rate limits and daily caps apply to every key; see rate limits and abuse. We suspend accounts that try to get around these controls.

Legitimate use is narrow and simple: check identifiers your own users gave you, for fraud prevention, store only the boolean and its date, and tell users in your privacy notice that you check contact details for that purpose. People can object through our opt-out form; suppressed identifiers are skipped and never charged.

Netflix, Amazon, Microsoft and Apple are named descriptively. MobileValidate is not affiliated with, or endorsed by, any of them.

#What are the key takeaways?

• A Netflix, Amazon or Microsoft check answers one question: is an account associated with this number? You get registered, not registered or unknown, with checked_at.
• All three phone checks run in real time and in bulk, for numbers from any country; Netflix and Amazon also have real-time e-mail checks, Microsoft does not.
• Presence is informative, absence is weak. A yes suggests a long-lived real number; a no is common among genuine users, and unknown means nothing.
• Combine presence with line type and HLR status, cap its credit, and never let absence alone block anyone.
• The checks never return names, subscription status, account details or e-mail addresses, and we refuse account takeover reconnaissance, credential stuffing targeting and enumeration.
• Unknown and inconclusive results are never charged. See current prices on the pricing page.