Lever 422 "email is invalid" when the agent pushes a candidate with a malformed scraped email

TL;DR: Validate and clean the email before the API call, and quarantine the ones that do not parse. The 422 means Lever rejected the exact string the agent sent - scraped emails often carry whitespace, truncation, or page artifacts that look fine at a glance but fail validation. Log the raw value so you are fixing the real string, not the one you assume was sent.

422 "email is invalid"

1. Log the exact email string the agent sent on the failed call. Expected: you see the raw value, often with a surprise like leading whitespace or a truncated domain.
2. Clean it: trim surrounding whitespace and strip common scrape artifacts like a mailto prefix. Expected: a clean address with no surrounding junk.
3. Validate the shape: it needs exactly one at-sign, a non-empty local part, and a domain with a dot and a valid-looking ending. Expected: malformed values are flagged before any API call.
4. Retry the candidate create with the cleaned address. Expected: a 200 or 201 from Lever.
5. Route the ones that still fail validation to a quarantine list for human review instead of retrying them. Expected: no more 422s from bad emails, and a human sees the questionable ones.

Use this when

• Lever returns 422 email is invalid on candidate create
• The email came from a scraper, a PDF parse, or a pasted list
• Some candidates in the same batch succeed while others fail

Not for this skill when

• The email is valid but the candidate already exists (that is a dedup problem, not a format problem)
• The 422 names a different field - fix that field instead
• The address looks valid and still fails - check for invisible unicode characters or a zero-width space from the scrape

Variant phrasings

• Lever API rejects candidate email format
• Lever 422 invalid email on candidate push
• scraped email fails Lever validation

Why it happens

Lever validates the email string server-side. Scrapers lift text from pages where addresses are truncated by styling, wrapped across lines, obfuscated against bots, or copied with surrounding punctuation - and the agent forwards that text verbatim. The API sees a malformed string, not the address the human reader inferred.

Edge cases

• Zero-width unicode characters from copy-paste pass a visual check but fail validation; strip non-printable characters during cleaning.
• Plus-addressed emails (a plus tag after the name) are valid and should not be stripped; only remove actual junk.
• Never guess a corrected email (appending a domain ending to a truncated domain creates a real address belonging to a stranger). Quarantine, do not invent.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstVlPwlLyNeViLOqlopTf8Q