Email Pattern Inference

Compare known name/email examples for a company and return the common format that fits them. Offline and unverified: this does not find emails, fetch websites, generate addresses or check whether a mailbox exists or accepts mail.

Input

{
  "companies": [
    {
      "domain": "example.com",
      "examples": [
        { "firstName": "Alice", "lastName": "Smith", "email": "alice.smith@example.com" },
        { "firstName": "Robert", "lastName": "Jones", "email": "robert.jones@example.com" }
      ]
    }
  ]
}

Supply 1–50 evidence groups, each with 1–20 observed name/email pairs. You must have permission to process these examples. Use a bare email domain, not a URL. Email domains are matched exactly: www.example.com and mail.example.com are not merged with example.com. Case, surrounding whitespace, IDNs and a trailing domain dot normalize. A bare public suffix such as co.uk is not an email domain. The exact normalized ASCII host, including any www. prefix, must be at most 253 characters with DNS labels of at most 63 characters; an IDN that exceeds these limits after punycoding returns free invalid_domain.

Names must be single ASCII-letter tokens after NFKC normalization, trimming and case folding. Accents, hyphens, apostrophes and multi-part names are unsupported, not transliterated or silently omitted. Email local parts get the same NFKC normalization and case folding for format comparison; this does not prove case-insensitive mailbox delivery. Unsupported or wrong-domain examples invalidate the group.

Formats considered (f / l mean first / last initial): first.last, firstlast, f.last, flast, first.l, firstl, last.first, lastfirst, first, last. No other naming conventions are inferred.

Identical normalized groups are processed once, including reordered examples and duplicate observations. Different evidence sets for one domain remain separate rows and can each bill. Distinct invalid groups remain separate.

Output

{
  "domain": "example.com",
  "evidenceCount": 2,
  "pattern": "first.last",
  "candidates": ["first.last"],
  "verified": false,
  "reasonCode": "inferred"
}

An inference requires at least two distinct names and mailboxes, and exactly one supported format matching every distinct observation. Multiple addresses for one name or one mailbox shared between names yield unknown_pattern; repeats of one pair are insufficient. candidates shows formats fitting the supplied evidence, including on insufficient/ambiguous results, but pattern is null unless inferred. These are hypotheses based on your examples, not a company-wide policy, identity or deliverability assertion. An unknown pattern does not mean an address is invalid.

Output omits names and email addresses, but Apify stores the submitted run input. Do not submit private contact data without the necessary permissions; configure retention/deletion in your account.

Billing

The billing unit is one inferred evidence group, not one email or company-wide verification. Unresolved evidence is not charged.

reasonCode	Meaning	Charged?
inferred	One supported format fits all independent observations	yes
invalid_domain	Not a supported bare email domain	no
invalid_examples	Unsupported names/emails or wrong-domain examples	no
insufficient_evidence	Fewer than two distinct observations	no
ambiguous	More than one supported format fits	no
unknown_pattern	Conflicting/unsupported convention or non-independent evidence	no

Limits

No discovery, SMTP, DNS, search, policy cache or history comparison. Two examples can fit one convention while other employees use another. Use a separate verification tool before treating an address as deliverable. Malformed batch shapes and over-limit strings are rejected at input validation. When the platform reports its charge limit, the sequential adapter stops starting further groups; remaining groups have no row.