Socialscan Email & Username OSINT Account Discovery

Socialscan Email & Username OSINT gives security, trust-and-safety, and brand-protection teams one validated dataset row per authorized email address or username. Each row contains per-platform account-status signals, counts, timing, and an optional public profile URL for username responses. The Actor uses public registration-validation responses; it does not need a caller login or account credentials.

Use this Actor when

Choose this focused workflow when you need a bounded account-footprint check for identifiers you own or are authorized to assess: inventorying your organization’s public signup footprint, screening a brand handle for impersonation risk, or triaging an abuse report before a human review. The output is account-status evidence for follow-up, not an identity assertion.

For a broad username profile-URL inventory across hundreds of sites, use Username OSINT Scraper after this focused registration-status check. That sibling Actor is designed for username-only public profile discovery; this Actor adds email input and keeps the upstream Socialscan capability map explicit.

Scope and responsible boundaries

This Actor is designed for public, authorized, read-only account-status research. It does not log in, retrieve private account content, submit passwords, send messages, perform password recovery, use breach data, bypass CAPTCHAs, or infer an email-to-username mapping. A TAKEN response means that a target registration-validation endpoint reported the identifier as already in use; it does not establish account ownership, identity, activity, or access to a public profile. Review findings against applicable laws, platform terms, and your organization’s authorization record.

The input includes authorizationConfirmed as an explicit caller-side confirmation. Use your Apify project access controls for email inputs and resulting datasets. Run the Actor for identifiers you own or are authorized to assess, with a documented review purpose.

Supported integrations

The Actor pins socialscan==2.0.1. Its paid contract is limited to the integrations that returned stable usable evidence in private cloud probes; upstream enum membership alone is not treated as a support promise. The supported keys and identifier types are:

Platform key	Display name	Username	Email	Optional profile URL
gitlab	GitLab	Yes	No	Yes
twitter	Twitter / X	Yes	Yes	Yes
tumblr	Tumblr	Yes	Yes	Yes

Leave platforms empty to use all three supported integrations. The Actor skips GitLab for email addresses because Socialscan does not expose an email registration check there, and reports that choice in platformsSkipped. The runtime deliberately excludes upstream integrations whose current endpoints did not provide stable usable cloud evidence.

Input and quick start

Pass full usernames or email addresses, select the authorization confirmation, and optionally narrow the platform set. Email addresses are normalized to lowercase; usernames are passed as entered. Up to 50 unique identifiers are accepted per run.

{
  "queries": ["gvanrossum", "person@example.com"],
  "authorizationConfirmed": true,
  "platforms": ["gitlab", "twitter", "tumblr"],
  "includeAvailable": false,
  "cacheTokens": true,
  "concurrency": 6,
  "requestTimeoutSecs": 15,
  "proxyConfiguration": {
    "useApifyProxy": true,
    "apifyProxyGroups": ["RESIDENTIAL"]
  }
}

includeAvailable defaults to false, so nested results focus on positive account-status signals plus invalid or inconclusive checks. Counts still report every compatible platform response. Set it to true when an audit needs the available responses in the nested array as well.

Output data

The dataset contains one record per accepted identifier whose compatible integrations return at least one usable response. A record is persisted only after local Pydantic validation and is coupled to one query-scanned pay-per-event charge.

Field	Meaning
query, queryType	The authorized normalized identifier and its inferred type (email or username). Treat query as sensitive.
platformsRequested, platformsTargeted, platformsSkipped	Resolved scope and type-incompatible selections.
platformsChecked	Compatible responses received, including errors.
platformsFound	Count of TAKEN account-status signals.
platformsAvailable	Count of AVAILABLE responses.
platformsInvalid, platformsErrored	Platform-specific validation and inconclusive-response counts.
platformsReturned, results	Nested rows after includeAvailable filtering; profileUrl is present only for a username response when upstream supplies a safe http(s) URL.
scanIncomplete, stopReason	Whether the run stopped early and the bounded reason when it did.
scanStartedAt, scanFinishedAt, scanDurationMs	UTC timing and elapsed milliseconds.
_note	Interpretation guidance that accompanies every persisted row.

Example dataset item:

{
  "query": "gvanrossum",
  "queryType": "username",
  "source": "socialscan",
  "socialscanVersion": "2.0.1",
  "scanStartedAt": "<RFC 3339 timestamp>",
  "scanFinishedAt": "<RFC 3339 timestamp>",
  "scanDurationMs": 3000,
  "platformsRequested": ["gitlab", "twitter", "tumblr"],
  "platformsTargeted": 3,
  "platformsSkipped": [],
  "platformsChecked": 3,
  "platformsFound": 2,
  "platformsAvailable": 1,
  "platformsInvalid": 0,
  "platformsErrored": 0,
  "platformsReturned": 1,
  "scanIncomplete": false,
  "stopReason": "",
  "results": [
    {
      "platformKey": "twitter",
      "platform": "Twitter / X",
      "queryType": "username",
      "status": "TAKEN",
      "valid": true,
      "success": true,
      "available": false,
      "message": "Username is already taken.",
      "profileUrl": "https://twitter.com/gvanrossum",
      "source": "socialscan",
      "checkedAt": "<RFC 3339 timestamp>"
    }
  ],
  "_note": "TAKEN is a registration-validation signal, not proof of identity, ownership, or public profile access."
}

The terminal key-value store also contains OUTPUT, RUN_SUMMARY, SUMMARY, and checkpointed STATE. Terminal outcomes are COMPLETE, VALID_EMPTY, PARTIAL, INVALID_INPUT, UPSTREAM_FAILED, or CONFIG_ERROR. Source diagnostics remain explicit rather than being represented as an available or not-found result.

When an integration needs a fresh connection, the Actor may retire its residential proxy session and retry only that route, up to three bounded rotations per run. RUN_SUMMARY records bounded route diagnostics with identifier, proxy-URL, and credential values redacted.

Pricing

This is a Pay per event (PPE) Actor. The primary event is $0.05 per accepted identifier scan, whether the identifier is an email or username; the row is charged only after the validated row write is coupled to the event. Actor start is configured at $0.00005 and Apify platform usage is charged separately according to the allocation shown in the live Pricing tab.

Worked examples before platform usage:

• One accepted identifier: 1 × $0.05 = $0.05, plus the configured actor-start event.
• Ten accepted identifiers: 10 × $0.05 = $0.50 for up to 10 result rows, plus the configured actor-start event.

The live Pricing tab is the source of truth for current event prices and platform usage. The ACTOR_MAX_PAID_DATASET_ITEMS and ACTOR_MAX_TOTAL_CHARGE_USD runtime guards provide additional bounded-cost protection when configured by the deployment.

API example

from apify_client import ApifyClient

client = ApifyClient("<APIFY_TOKEN>")
run = client.actor("khadinakbar/socialscan-osint").call(
    run_input={
        "queries": ["gvanrossum"],
        "authorizationConfirmed": True,
        "platforms": ["gitlab", "twitter", "tumblr"],
    }
)

items = list(client.dataset(run.default_dataset_id).iterate_items())
for item in items:
    print(item["query"], item["platformsFound"], item["results"])

For a lightweight HTTP integration, call the Apify Actor API with the same JSON input and read the default dataset after the run. Treat the dataset and RUN_SUMMARY readback as the completion signal; a run status alone does not prove that useful rows were persisted.

AI-agent and MCP workflow

The Actor can be called through the Apify MCP server at https://mcp.apify.com. Give an agent a scoped, authorized task such as:

Check these two organization-controlled handles on GitLab, X, and Tumblr, return the dataset readback with TAKEN versus AVAILABLE, preserve inconclusive source responses, report the requested scope, provenance, outcome, and cost, and stop before any login or private-data action.

Agents should pass authorizationConfirmed: true only when the caller has supplied the required authorization, keep the platform scope small when the question is narrow, and read back both the dataset and terminal summary. PARTIAL, VALID_EMPTY, INVALID_INPUT, and UPSTREAM_FAILED are meaningful outcomes, not interchangeable success states.

Workflow scenario

A trust-and-safety analyst starts with a brand-owned handle and a controlled test mailbox. The Actor checks the selected public registration endpoints, then returns a row with the platform statuses and any profile URL supplied by the upstream integration. The analyst next reviews each TAKEN signal against internal ownership records and platform evidence, compares the timestamp and scope, and exports only the findings needed for the case file. Broader username profile discovery continues with the linked username-only workflow, while inconclusive source responses are routed to a later retry or manual review.

Builder's note

I designed this Actor as a compact registration-signal workflow rather than a broad identity finder. My goal was to keep the source, the supported routes, the account-status vocabulary, and the billable dataset row aligned so a human reviewer can understand exactly what each result means.

Evidence and freshness

The implementation records the Socialscan version in every dataset row so later source behavior can be compared with the result provenance. The paid contract intentionally covers GitLab, Twitter / X, and Tumblr: these routes provide the focused public registration-validation signals represented by this Actor. Upstream references: Socialscan source and README and Socialscan on PyPI.

Re-check the supported integrations and the live Pricing tab after an upstream or Actor build change. Keep release evidence separate from user-facing output, and use dataset plus key-value-store readback to validate an operational change.

Coverage and recovery

Public registration endpoints can change, throttle, return unexpected content, or require platform-side tokens. The Actor uses one bounded request timeout per check, optional cached token warm-up, a sticky Apify proxy session by default, and per-platform diagnostic rows for inconclusive responses. It keeps retries measured and retains the Socialscan source provenance for each signal.

When a run is partial, inspect RUN_SUMMARY for the platform scope, diagnostic counts, warnings, and stopping reason. Reduce concurrency or narrow platforms, retry after a platform cooldown, and compare delayed dataset readback before drawing a conclusion. Empty results are a source-level observation for the selected checks and should be reviewed with the requested scope.

License and attribution

The Actor uses the upstream Socialscan package under its published Mozilla Public License 2.0 terms. Review the Socialscan license and the relevant platform terms before operating a scan. This Actor is a technical signal collection tool; the caller remains responsible for authorization, privacy, retention, and lawful use of any supplied identifier or resulting dataset.