customer.io 422 invalid email attribute on person update

TL;DR

Customer.io validates the email attribute on person updates; a malformed value returns 422. Check the email format client-side, strip whitespace and junk, and only then call identify.

customer.io 422 invalid email attribute on person update

Use this when

• Customer.io returns 422 on person update.
• The error detail names the email attribute.
• Updates from a new data source suddenly 422.

Not for this skill when

• 400 errors from malformed JSON bodies.
• 401 from a bad site ID or key.
• Event 422s, which validate event data instead.

Steps

1. Capture the exact payload that returned 422 and inspect the email value. Verify: you can see the bad value (empty, whitespace, no at-sign).
2. Add client-side email validation before the identify call. Verify: the captured bad values fail validation locally.
3. Trim whitespace and lowercase the email before sending. Verify: edge values normalize to valid addresses.
4. For existing bad profiles, fix the source data then re-identify. Verify: the corrected profiles update with 200.
5. Add a test that feeds garbage emails and asserts the 422 never reaches production. Verify: the test passes on the current code.

Variant phrasings

customer.io 422 person update email

The endpoint-angle search.

customer.io invalid email attribute

Common phrasing of the error.

customer.io identify 422 error

The identify-angle search.

Compatibility: Customer.io Track API v2; applies to identify and person-attribute updates.

Why it happens

The email attribute is the identity key for people in Customer.io, so it gets validated strictly. Pipelines that pass through raw user input or scraped rows hand it strings that are not emails, and the API refuses the whole update.

Edge cases / pitfalls

• One bad attribute can reject an otherwise fine update; validate each field.
• Blank-string emails fail the same way as malformed ones.
• Device and attribute updates share the person; a bad email blocks all of them.
• Do not invent placeholder emails to satisfy validation; that creates fake people.
• Blank-string emails fail the same way as malformed ones; treat blank as invalid, not as unset.
• On some plans the email attribute cannot be changed after creation; check before planning a re-identify.

Provenance

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

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

Thread query: customer.io 422 invalid email attribute on person update

TL;DR: Customer.io validates the email attribute on person updates; a malformed value returns 422. Check the email format client-side, strip whitespace and junk, and only then call identify.