How to check if a phone number has an X (Twitter) account

To check if a phone number has an X (formerly Twitter) account, run a registration check: send the number to an API and get back registered, not registered or unknown, with the time of the check. With MobileValidate that's checks: ["x"], in real time or in bulk jobs. This kind of X number lookup confirms that an account exists. It never reveals which account it is.

That last point is what separates a registration check from the "who is behind this number?" lookups people sometimes search for. This guide explains what the answer means on X specifically, why the phone number tells you less on X than on a messaging app, why we refuse to return profiles (with the 2022 Twitter incident as the reason), and how to run the check in real time and in bulk.

#What does an X number check actually tell you?

It tells you whether an X account is associated with the number at the time of the check, and nothing else. Every answer has one of three outcomes, plus checked_at:

A true is evidence that the number is a real, working phone line someone has used for an online identity. X sends a text message with a code when a number is added during sign-up or later in settings (X Help Center). A burner generated a minute ago rarely has that history.

One detail is specific to X: according to its help centre, "you can have the same phone number associated with up to 10 X accounts" (X Help Center). So true means "one or more accounts", never a particular account, and never a count.

#Is an "X number lookup" the same as finding someone's profile?

No. When people type "x number lookup" or "how to check x number", some want to know whether a number is on X; others want to know who it belongs to. MobileValidate answers only the first question. There is no handle, display name, photo, bio, follower count, post, location or profile link in the response, and we never infer age, gender or any other trait.

The X check service page carries the same rule. If your task needs a name or a profile, a registration check is the wrong tool, and we won't run it for that purpose.

#Why do we never return profiles from an X check?

Because mapping phone numbers to X accounts has already caused real harm. On 5 August 2022, Twitter disclosed a vulnerability that "allowed someone to enter a phone number or email address into the log-in flow in the attempt to learn if that information was tied to an existing Twitter account, and if so, which specific account". It had been reported through the bug bounty programme in January 2022 and came from a code update in June 2021. Twitter later confirmed that "a bad actor had taken advantage of the issue before it was addressed", and said it was "particularly mindful of people with pseudonymous accounts who can be targeted by state or other actors" (Twitter Privacy Center, 2022).

On 23 December 2022, Ireland's Data Protection Commission opened an inquiry after media reports of collated datasets covering "approximately 5.4 million Twitter users worldwide". The datasets "were reported to map Twitter IDs to email addresses and/or telephone numbers" (DPC, 2022).

The lesson for a checking service is direct. The dangerous output was the link between a number and a specific account, and the dangerous behaviour was feeding in numbers at scale. So we built the X check around both:

• No link to an account. The answer is a yes, no or unknown. If a data source ever returned identifying fields, they would be dropped before reaching your account.
• No enumeration. A request containing 20 or more consecutive numbers is refused with 403 suspected_enumeration, generated e-mail lists are refused the same way, and every account has a daily identifier cap (GET /v1/limits). See rate limits and abuse.
• A way out for people. Anyone can object to checks on their number through the opt-out form. Suppressed numbers are skipped and never charged.

#Why is the phone number a weaker signal on X?

Because on X the number is optional, and three platform rules make it more so.

• Sign-up without a number. X's sign-up flow asks for a "name and phone number or email address", and also offers Google and Apple sign-in (X Help Center). Many accounts never get a number.
• Less reason to add one for security. In February 2023 Twitter said it had seen phone-number-based 2FA "used - and abused - by bad actors", and limited text-message two-factor authentication to subscribers from 20 March 2023 (Twitter, 2023). Authenticator apps and security keys don't need a number.
• Numbers get added during verification. When X locks an account and asks the owner to verify it, one route is by phone, and the help centre warns "we will associate this phone number with your account". Email and captcha routes also exist (X Help Center). Some numbers are attached only because of such a check.

Discoverability is the other X-specific factor. Each account has settings called "Let others find you by your phone" (in the apps) or "Let people who have your phone number find you on X" (on the web), under Settings and privacy → Privacy and safety → Discoverability and contacts. X states that phone numbers "are not publicly displayed on X, even if you have enabled the setting" (X Help Center). The setting controls whether people who have your number in their contacts can find you. Our check shows no account to anyone in any case, but privacy choices like this are one reason unknown answers occur.

The practical reading: true is useful supporting evidence, false means "probably no number attached", and unknown means nothing. Never treat a missing X answer as a sign that a person is fake.

#What are legitimate uses for an X check?

Use it on numbers people gave you, to protect your service or to improve data you already hold.

X is rarely the strongest single signal; it adds independent evidence alongside other platforms. Our guide to account-presence signals at sign-up covers scoring and friction tiers, and the Facebook and Instagram guide covers the Meta platforms. For numbers that look virtual, see VoIP number detection.

#Which uses do we refuse?

Anything that turns a registration answer into a way of finding, unmasking or contacting people who didn't ask for it:

• De-anonymisation. Trying to learn who runs a pseudonymous or critical account, or confirming a suspicion about one.
• Finding a person. Checking an ex-partner, a debtor, a journalist, an applicant or anyone else to see whether they are on X.
• Audience building. Running bought, scraped or generated number lists to find "all X users" in a range or region, or to target people with unsolicited messages.
• Eligibility decisions. Using presence on X to decide credit, employment, housing or insurance, or as a proxy for any protected trait.

Our acceptable use policy forbids all of these, and the enumeration limits above enforce the most common pattern technically.

#How do I check a number for X in real time?

Use POST /v1/lookup with up to 100 numbers per request. The code is x.registered; the aliases x and twitter both work, and results always appear under checks["x.registered"]. This request uses test numbers, which are free and never reach a real network:

curl https://api.mobilevalidate.com/v1/lookup \
  -H "Authorization: Bearer $MOBILEVALIDATE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"numbers": ["+447700900001", "+447700900002", "+447700900003"],
       "checks": ["x"], "wait": 5}'

In test mode, +447700900001 answers registered, +447700900002 not registered and +447700900003 unknown with reason: "UPSTREAM_TIMEOUT", so you can build all three branches before going live. Each result carries registered, status, confidence, checked_at, cached, billed and reason; the real-time lookups reference shows the full shape.

For sign-up flows:

• Keep wait short, such as 3 to 5 seconds. If the answer is still pending, treat it as unknown for this decision and pick it up later by polling GET /v1/lookups/{id} or by webhook.
• Combine checks in one call, for example ["x", "instagram", "whatsapp", "carrier"], instead of making one request per platform.
• Pass default_country if your form collects national-format numbers.

#How do I check a list of numbers in bulk?

Use a bulk job: up to 50,000 numbers per job, uploaded as a CSV with a phone column, or through the dashboard without code.

curl https://api.mobilevalidate.com/v1/jobs \
  -H "Authorization: Bearer $MOBILEVALIDATE_API_KEY" \
  -F file=@opted-in-customers.csv -F checks=x,threads,instagram
# then GET /v1/jobs/{id}?wait=30 and GET /v1/jobs/{id}/download?format=csv

The CSV download has x.registered.status, x.registered.registered and x.registered.billed columns per row. To list one slice through the API, filter the results, for example GET /v1/jobs/{id}/results?service=x.registered&registered=true. If you hold e-mail addresses rather than numbers, the X e-mail check (x.email) answers the same question for an address, in bulk jobs only. The bulk jobs guide covers file formats and limits.

Two habits keep stored answers honest: never overwrite a stored true or false with a later unknown, and keep checked_at next to every answer, because carriers recycle numbers and people remove them from accounts.

#What does an X check cost, and how do I control it?

You pay per number checked, only for conclusive answers. Real-time and bulk checks have separate prices; see current prices on the pricing page. Cost controls:

• Free estimate. POST /v1/jobs/estimate takes the same body as a job, checks nothing, and returns the maximum cost with invalid, duplicate and cached counts.
• Cost cap. Pass the estimate's max_cost, or a lower amount, on the job. A real-time request with max_cost is refused with 402 cost_limit_exceeded if it could cost more.
• Unknowns are free. Unknown or inconclusive results (timeouts, unsupported countries, invalid input, duplicates) are never charged.
• Cache. Repeat checks inside the freshness window come from your account's cache for free; max_age: 0 forces a fresh, billed check.

#What are the consent and privacy rules?

• Lawful basis. Checking a number is likely to be processing of personal data. Under the GDPR you need a lawful basis (Article 6), and scoring risk from the answer can be profiling (Article 4(4)). Confirm with your counsel what applies to your flow.
• Data minimisation. Store the answer, its checked_at and your decision, not raw responses (Article 5(1)(c)).
• Human review. Keep decisions with significant effects, such as refusing service, behind meaningful human review (Article 22).
• Presence isn't consent. A true on X gives you no right to contact anyone there or anywhere else.

X and Twitter are named here descriptively. MobileValidate is not affiliated with X Corp.

#What are the key takeaways?

• An X check returns registered, not registered or unknown, with checked_at. It never returns a handle, name, photo or profile.
• On X the number is optional, can be shared by up to 10 accounts and is never displayed, so true is useful evidence, false is weak and unknown is no information.
• The 2022 Twitter incident showed the harm of mapping numbers to specific accounts at scale; that's why we return no account link and refuse enumeration.
• Good uses: sign-up quality, lead scoring, recovery-number reviews and channel planning for opted-in customers. De-anonymisation, people-finding and audience building are refused.
• x.registered (alias x or twitter) runs in real time and in bulk, for every supported country; x.email is bulk only.
• Estimate first for free, pay only for conclusive answers, and start from the X check.