FB UID Check

Check Facebook UIDs directly against Facebook and learn whether each one is alive, dead, or blocked — no login cookie, no third-party API. Give it up to 500 user/profile IDs; it returns one result item per UID in a single shared envelope, whether the check succeeds or fails.

What does fb-uid-check do?

It performs a direct UID liveness check: for each UID it fetches the public mobile profile page (https://m.facebook.com/profile.php?id=<uid>) with an iPhone user agent through Apify Proxy, then applies a discriminator proven live against known-good and known-bad UIDs. It does not log in, render JavaScript, use a cookie, or call any third-party checker — the old SheetSubmit /fb/check endpoint proxied check.fb.tools, while this Actor owns the check end to end.

Why use fb-uid-check?

• Batch triage: screen up to 500 UIDs per run and instantly see which ones are still alive.
• No credentials needed: UID checks are public-page reads, so there is nothing to expire and nothing to rotate.
• Machine-readable outcomes: every item carries valid plus a stable statusName (valid, dead, blocked), and every failure carries a stable error.code (invalid_input, rate_limited, upstream_error, service_unavailable) plus a retryable flag, so pipelines can branch without parsing messages.
• Platform-native: scheduling, API access, integrations, proxy rotation, and run monitoring all come from Apify. Every request goes through Apify Proxy, because Facebook blocks bare datacenter IPs.
• Cheap: one lightweight HTML fetch per UID, no browser, short pauses between requests to stay under rate limits.

What data can fb-uid-check extract?

Field	Type	Description
valid	boolean | null	true when the UID has a live profile, false when dead/blocked
statusName	string | null	valid, dead, or blocked
statusMessage	string | null	Human-readable detail (includes the profile name when live)
error	object | null	{ code, message, retryable } on failure, null on success
input	string | null	Echo of the UID that was checked

A negative answer (valid: false) is still success (ok: true); error only means "the check itself could not run". You can download the dataset in various formats such as JSON, HTML, CSV, or Excel.

How the check works

The discriminator was proven live on 2026-10-13 by fetching candidate endpoints for two known-live UIDs (61592912563278, 61592823917254, live fixtures from the project's cookie data) and three known-dead UIDs (123456789012345, 100000000000001, 999999999999999):

UID	Ground truth	Page size	<title>	og:title	fb://profile/<uid>
61592912563278	live	~10 KB	profile name	present	present
61592823917254	live	~10 KB	profile name	present	present
123456789012345	dead	~43 KB	Facebook	absent	absent
100000000000001	dead	~43 KB	Facebook	absent	absent
999999999999999	dead	~43 KB	Facebook	absent	absent

So valid requires both a non-empty og:title meta tag and the fb://profile/<uid> deep link; the generic Facebook-titled shell with no profile markers means dead. Generic error pages (title Error, "Sorry, something went wrong") and login walls are classified as transient errors (upstream_error, retryable), never as dead — an ambiguous page must not kill a UID.

How to check Facebook UIDs

1. Paste 1–500 numeric UIDs into the uids input (each 5–20 digits; duplicates are checked once).
2. Leave proxy configuration on Apify Proxy (required — the run falls back to direct only if proxy setup errors).
3. Run the Actor and open the dataset: one item per UID, in input order.
4. Branch on ok / valid / statusName / error.code. Retry retryable: true codes (rate_limited, upstream_error, service_unavailable) with backoff; fix the input for invalid_input.
5. Read the OUTPUT key-value record for the run summary (total, succeeded, failed, errorsByCode).

How much does a run cost?

The Actor uses no browser and no pay-per-event billing: you pay only Apify compute units (seconds of runtime) plus Apify Proxy traffic (one ~10–45 KB page fetch per UID). A small batch finishes in seconds; a full 500-UID run takes a few minutes because of the politeness pause between requests.

Input

See the input tab for full configuration options. uids is a UID array (1–500 checkable items); malformed entries (wrong type, empty, not 5–20 digits) and items past the 500-UID cap each produce their own invalid_input dataset item instead of failing the run. proxyConfiguration uses the standard proxy editor and defaults to Apify Proxy.

{
    "uids": ["61592912563278", "123456789012345"],
    "proxyConfiguration": { "useApifyProxy": true }
}

Output

One envelope item per UID, plus an OUTPUT summary record. Example success item (live UID):

{
    "ok": true,
    "actor": "fb-uid-check",
    "input": "61592912563278",
    "valid": true,
    "statusName": "valid",
    "statusMessage": "Profile is live (\"Ryan Prasetyo\").",
    "error": null,
    "checkedAt": "2026-10-13T12:00:00.000Z",
    "runId": "local"
}

Example negative item (dead UID — still success):

{
    "ok": true,
    "actor": "fb-uid-check",
    "input": "123456789012345",
    "valid": false,
    "statusName": "dead",
    "statusMessage": "No live Facebook profile for this UID (dead or never existed).",
    "error": null,
    "checkedAt": "2026-10-13T12:00:00.000Z",
    "runId": "local"
}

Example error item (malformed UID):

{
    "ok": false,
    "actor": "fb-uid-check",
    "input": "abc",
    "valid": null,
    "statusName": null,
    "statusMessage": null,
    "error": {
        "code": "invalid_input",
        "message": "Field \"uids\": received \"abc\"; constraint: each UID must be 5-20 digits.",
        "retryable": false
    },
    "checkedAt": "2026-10-13T12:00:00.000Z",
    "runId": "local"
}

Run summary (OUTPUT key):

{
    "actor": "fb-uid-check",
    "runId": "local",
    "startedAt": "2026-10-13T12:00:00.000Z",
    "finishedAt": "2026-10-13T12:00:05.000Z",
    "durationMs": 5123,
    "total": 2,
    "succeeded": 2,
    "failed": 0,
    "errorsByCode": {}
}

Tips

How do I keep runs cheap?

Batch up to 500 UIDs per run, schedule off-peak, and cache valid results — UIDs rarely change state between runs, so re-check only what matters.

Why did a live UID come back dead?

The most common cause is proxy-IP treatment: Facebook sometimes serves the generic shell to flagged egress IPs. Retry the UID later (a fresh proxy IP usually renders the profile), and never delete data on a single dead reading for high-value UIDs — confirm with a second run first.

What does blocked mean?

Facebook confirms something exists at that UID but serves "content isn't available" instead of a profile — the account is restricted, banned, or otherwise withheld. Treat it like dead for triage, but different for forensics.

FAQ, disclaimers, and support

Our Actors are ethical and do not extract any private user data, such as email addresses, gender, or location. They only read each UID's public profile page. We therefore believe that our Actors, when used for ethical purposes by Apify users, are safe. However, you should be aware that your results could contain personal data. Personal data is protected by the GDPR in the European Union and by other regulations around the world. You should not scrape personal data unless you have a legitimate reason to do so. If you're unsure whether your reason is legitimate, consult your lawyers.

Respect Facebook's terms of service, and expect rate_limited if you run large batches back-to-back. Found a bug or need a field? Use the Issues tab. For programmatic access see the API tab.